Announcement

Collapse
No announcement yet.

Benchmarking The Linux 2.6.24 Through 2.6.29 Kernels

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic Benchmarking The Linux 2.6.24 Through 2.6.29 Kernels

    Benchmarking The Linux 2.6.24 Through 2.6.29 Kernels

    Phoronix: Benchmarking The Linux 2.6.24 Through 2.6.29 Kernels

    With the release yesterday of the Linux 2.6.29 kernel, we have set out to explore how the desktop performance has evolved over the past six major kernel releases. On a few occasions in the past we have provided kernel benchmarks (at one point even benchmarking 12 kernels), but this time around we have included nearly two dozen benchmarks using the Phoronix Test Suite. How has the Linux performance evolved since the release of the Linux 2.6.24 kernel back in early 2008? Well, simply put, the Linux 2.6.29 kernel in a few areas does pack some serious performance boosts.

    http://www.phoronix.com/vr.php?view=13622

  • Wyatt
    replied
    Originally posted by smitty3268 View Post
    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.... :/

    Leave a comment:


  • smitty3268
    replied
    Originally posted by Wyatt View Post
    Large projects like FFmpeg?
    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.

    Leave a comment:


  • Wyatt
    replied
    Originally posted by Nexus6 View Post
    I'm certain that there are cases where icc does outperform GCC by a larger margin but I've not seen it on large projects.
    Large projects like FFmpeg?

    Leave a comment:


  • Kano
    replied
    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.

    Leave a comment:


  • Nexus6
    replied
    Originally posted by lsatenstein View Post
    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.

    Leave a comment:


  • lsatenstein
    replied
    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.

    Leave a comment:


  • Kano
    replied
    I only tested OpenSSL, because i know of the extreme diffs between 32+64 bit. But in your article you stated that you used 64 bit for all. Then those values are extra low.

    Leave a comment:


  • Michael
    replied
    From the GraphicsMagick maintainer:

    ###


    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.

    Leave a comment:


  • Michael
    replied
    Originally posted by Kano View Post
    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
    On all Phoronix desktop test machines, EIST is disabled from the BIOS.

    Leave a comment:

Working...
X