Sorry. I don't get what you are trying to say other than quoting a wikipedia article detailing the amount of available addresses.
Originally Posted by ssam
What was tested is a 32 bit OS environment on a 32 bit core processor. This isn't taking advantage of multiprocessing. I wonder if there is a difference in performance.
One can make the argument that a 32bit processor on a 32 bit machine should not have a decrease in performance. But, what if there is an increase in performance between 7.04 to 8.10 by the advent using multiprocessing if those applications use this advantage.
the tests were done on a core duo. that is a dual core CPU, so it can and is doing multiprocessing.
What about power settings? Is there a chance that the CPU downclocked while running these tests, or is the userspace governor set to Performance? That could quite easily cause a major performance differential with the memory accesses and such.
EIST was disabled during testing. The Core Duo was running at its full speed the entire time.
Originally Posted by Pitabred
Personally, I don't think PTS in it's current form is suitable for benching distro version vs distro version. Since a distro is a culmination of pre-built packages, to do a A/B test items such as the encoding tests and such should utilize the distro's pre-builts instead of compiling them from source which may not have the same build flags.
Total bullshit. You're too lazy to look at wine forum? It's wine problem not CFS and you have to tune CFS for wine... Best gaming experience (especially with wine) on open solaris XD
Originally Posted by thacrazze
And one more thing, some games under wine worked better with SD Scheduller (it was piece of cra... in my opinion, especially for desktop use), but not native.
Last edited by kraftman; 10-27-2008 at 04:18 PM.
Well, (K)Ubuntu always felt to me as somewhat slower comparing to other distributions so it's not that surprising for me.
Slowdown in GCC - compilation time is not regression - newer GCC is always armed with better, more sophisticated optimizations and resulting with longer compilation times - no shocker here.
Java performance is a shocker here anyway.
SQLite and Python performance may be improved *vastly* just using -O3 for CFLAGS - sometimes disregarded (on Phoronix) Linux distributions can be helpful...
That could make sense. After all, the compilation time is not a big deal as long as the resulting binaries are fast. BUT, as the test shows, the resulting binaries, at least of audio codecs, are much slower too.
Originally Posted by reavertm
It would be good to test the same LAME binary on the different Ubuntu versions (or just on different kernels). That way we could know if the problem is in GCC doing wrong optimizations or on a pure kernel regression.
Thanks for the tests!
Hhmmm, looking through the archives I've found some previous benchmarks that don't seem to confirm the issues found in this latest one.
For example, in this article Ubuntu 7.10 and 8.04 are compared and their performance is the same (for example, using LAME to encode an audio file takes the same time, while in the last article it's 53 vs. 116 secs).
Also the article comparing 12 kernel versions shows that all perform about the same.
So I'm rather inclined to think that something strange is happening with the hardware used to test. Maybe some driver regression that affects that laptop is causing all the troubles...