Page 1 of 3 123 LastLast
Results 1 to 10 of 25

Thread: Benchmarks Of GCC 4.2 Through GCC 4.7 Compilers

  1. #1
    Join Date
    Jan 2007
    Posts
    15,703

    Default Benchmarks Of GCC 4.2 Through GCC 4.7 Compilers

    Phoronix: Benchmarks Of GCC 4.2 Through GCC 4.7 Compilers

    To see how the GCC 4.7 release is shaping up, for your viewing pleasure today are benchmarks of GCC 4.2 through a recent GCC 4.7 development snapshot. GCC 4.7 will be released next March/April with many significant changes, so here's some numbers to find out if you can expect to see any broad performance improvements. Making things more interesting, the benchmarks are being done from an AMD FX-8150 to allow you to see how the performance of this latest-generation AMD processor architecture is affected going back by GNU Compiler Collection releases long before this open-source compiler had any optimizations in place.

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

  2. #2
    Join Date
    Dec 2007
    Location
    Edinburgh, Scotland
    Posts
    597

    Default

    Meaningful tests for once (except maybe ffmpeg which uses assembler for it's critical code)

    It would be interesting to bisect down the regressions in 4.7 - I was under the impression we should be seeing speed ups with 4.7 not slow downs

    Can't wait to see the same benchmarks on your Sandybridge 2630QM

    You should really consider adding flattr to your articles

  3. #3
    Join Date
    Jun 2011
    Posts
    3

    Default measuring optimization potential

    This test basically measures the optimization potential that inner loops have. In other words it measures how bad the inner loop was written. If your inner loop heavily relies on the compiler figuring out how to best convert it to machine code, you should really work on it. I am looking at you, GraphicsMagic. Obviously encoder writers on the other hand have figured out this fact long ago and made their inner loop performance compiler agnostic.

  4. #4
    Join Date
    Mar 2009
    Posts
    141

    Default

    I'd rather have seen a comparison of how well the compilers optimize rather than how features of a particular new processor becoming supported over time affects performance. Graphite was added at some point in these versions. I haven't yet seen any tests on it.

    -march implies -mtune. No need for both.

  5. #5
    Join Date
    Dec 2009
    Posts
    492

    Default

    Since gcc 4.7 is not out yet, it's very likely performance and optimization are yet to be addressed. So this comparison may be a bit ahead of its time.

  6. #6

    Default

    I'm totally confused - is this a test of GCC compilers or GCC + LLVM backend?

    The table on the first page lists LLVM backend for all GCC versions so I've no idea what to think.

  7. #7
    Join Date
    Oct 2010
    Posts
    352

    Default

    -march=native was a great choice, but maybe -O2 would have been better then -O3, the gcc documentation recomends using -O2 as -O3 does some risky optimisations.

  8. #8
    Join Date
    Aug 2007
    Location
    Europe
    Posts
    401

    Default

    Quote Originally Posted by bug77 View Post
    Since gcc 4.7 is not out yet, it's very likely performance and optimization are yet to be addressed. So this comparison may be a bit ahead of its time.
    No, it is very timely. Now the developers have a chance of addressing these issues.

  9. #9
    Join Date
    Oct 2008
    Posts
    3,252

    Default

    Quote Originally Posted by oglueck View Post
    This test basically measures the optimization potential that inner loops have. In other words it measures how bad the inner loop was written. If your inner loop heavily relies on the compiler figuring out how to best convert it to machine code, you should really work on it. I am looking at you, GraphicsMagic. Obviously encoder writers on the other hand have figured out this fact long ago and made their inner loop performance compiler agnostic.
    Encoders optimize by writing those inner loops in assembly by hand and completely bypassing the compiler.

  10. #10
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote Originally Posted by FireBurn View Post
    Meaningful tests for once (except maybe ffmpeg which uses assembler for it's critical code)

    It would be interesting to bisect down the regressions in 4.7 - I was under the impression we should be seeing speed ups with 4.7 not slow downs

    Can't wait to see the same benchmarks on your Sandybridge 2630QM

    You should really consider adding flattr to your articles
    well if YOU consider an old 8.2 release (ffmpeg/avconv dev's still recommend you use the latest git version or at least a current 0.8.6) doing a virtually useless antiquated and tiny avi to vcd encode (who today even uses vcd , its all HD 1080P BR or at least 720P from HD MKV sources) anything like a reasonable test in 2011/12

    or come to that, using an even older x264 v2010-11-22 without lots of current SIMD improvements or any AVX come to that ,to encode a non HD content on an AVX ready CPU is far beyond reason for a perceived improved speed test, when a 2 minute GIT pull is clearly needed to get the latest code to see large speed improvements.....

    its not like the ffmpeg and x264 devs wont give you advice of suitable samples and command lines best suited for the GIT to use and integrate in your current phoenix test suite
    Last edited by popper; 12-02-2011 at 04:23 PM.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •