If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
No announcement yet.
Benchmarking The Linux 2.6.24 Through 2.6.29 Kernels
I have confirmed there are configuration differences between Ubuntu mainline ppa kernels. I compared x86_64 versions of 2.6.28 and 2.6.29 with the first command below. I then reduced it down to a more basic form with the second command.
Some of the new options enabled seem to be debugging options.
The new U kernel have got speedstep active by default even without manageing tool, but thats not really problematic, you could disable EIST in bios or you can use a gui tool (or echo to set the system to performance mode for benchmarking. The rest is not important. Saidly mainline kernels do not provide aufs or squashfs modules (2.6.29 has at least a not backwards compatible squashfs 4.0), so basically you would need squashfs 4 for all older kernels + aufs for all to combine em into a multi kernel live image for better testing.
As far as Linux kernel improvements go, there is no telling what the cause of the boost is, but the most obvious improvements would be to make best use of the caches by carefully managing thread affinity, and by minimizing unnecessary cache thrashing during synchronization. Other improvements could be related to scheduling floating point operations.
Most open source applications are traditional single threaded. People in research labs may develop multi-thread programs but they are not broadly available or easy to use. Applications like GraphicsMagick make OpenMP generally available to test with and easy to use. It is a good test case for Linux kernel developers. Recently the valgrind author was using GraphicsMagick as a test case (GraphicsMagick did good).
It shouldn't be surprising that OpenMP performance improves in recent kernels.
I would be very interested to know if the current applications (graphmagik ffmpeg, etc.) were compiled with the compiler in use at the time the kernel was created.
I understand, that Intel has an optimising C compiler that produces substantially faster code then does gcc. Since the bulk of installations are on Intel / AMD platforms, it would be interesting to have a comparison of the last kernel and one compiled with Intel's C compiler.
I understand, that Intel has an optimising C compiler that produces substantially faster code then does gcc.
I think you'd be surprised at the performance difference between GCC 4.x and ICPC 10.x compiled code. It's not as huge as you might expect - in mixed workloads, I've typically seen anything from GCC being a couple of percent faster to 5-6% slower. I'm certain that there are cases where icpc does outperform GCC by a larger margin but I've not seen it on large projects. GCC has come a long way towards smarter and more extensive optimisation in the 4.x series.
So last live test i made was using 2.6.29 - 32 bit, but even that was only 35.2. High values only possible with 64 bit, but so low values that you have got for OpenSSL are more or less impossible for a 64 bit system.
That test had icc compiling to the 686 target and gcc targeting 486 (i think) so it's not exactly a fair test. Although it wouldn't surprise me if it did still win by a big margin.
Turns out Mike noticed that, too. Seems my bookmark is obseleted by this third post; looks like if you feel like running in the danger zone, there's some improvements in line for GCC. But I don't know many people that commonly run trunk code for their compiler.... :/