Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21

Thread: Benchmarking GCC 4.2 Through GCC 4.8 On AMD & Intel Hardware

  1. #11
    Join Date
    Dec 2007
    Location
    Edinburgh, Scotland
    Posts
    575

    Default

    I'd love to see ffmpeg compared with ASM switched off - so we can actually see which is the better compiler of C code and produces the faster binaries - yes I know no one in their right mind would use these binaries on a real system but the results could be normalised against the ASM builds

  2. #12
    Join Date
    Jan 2010
    Location
    Portugal
    Posts
    945

    Default

    Quote Originally Posted by bug77 View Post
    A couple of interesting things I see:
    1. In C-Ray, intel was faster with gcc 4.2, amd ends up faster with gcc 4.7/4.8.
    2. In FLAC audio encoding, the stiuation is actually reversed (though the differences are smaller this time): amd start out on top end ends up at the bottom.
    Now the question is why? I wish Phoronix had a big editorial staff...

  3. #13
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    Quote Originally Posted by devius View Post
    Now the question is why? I wish Phoronix had a big editorial staff...
    (1) In 4.7 Gcc recieved SMP improvements, for example bulldozer rendering went up around 50%. There was an article on it.

  4. #14
    Join Date
    Dec 2009
    Posts
    492

    Default

    Quote Originally Posted by devius View Post
    Now the question is why?
    Basically, because there's no free lunch. Few optimizations will improve performance across the board. Uusually you win some, you gain some.

  5. #15
    Join Date
    Jan 2010
    Location
    Portugal
    Posts
    945

    Default

    Quote Originally Posted by crazycheese View Post
    (1) In 4.7 Gcc recieved SMP improvements, for example bulldozer rendering went up around 50%. There was an article on it.
    But why didn't those changes also affect Intel systems the same way?

  6. #16
    Join Date
    Jan 2009
    Posts
    1,395

    Default

    Quote Originally Posted by devius View Post
    But why didn't those changes also affect Intel systems the same way?
    My guess would be that intel's architecture , as far as smp is concerned, hasn't changed in ages (since around nehalem's qpi).

  7. #17
    Join Date
    Dec 2007
    Posts
    677

    Default

    Pretty good improvements there - big thanks to everyone who contributes to GCC.

    I love it when a product keeps being developed and improved.

  8. #18
    Join Date
    Oct 2008
    Posts
    3,124

    Default

    Quote Originally Posted by devius View Post
    But why didn't those changes also affect Intel systems the same way?
    I think someone here once said that the CRay results were heavily linked with how aggressively the compiler was at inlining code (with more inlining = faster), so it's possible that affects each processor differently. (Differently sized caches, branch predictors, etc.)

  9. #19
    Join Date
    Jun 2009
    Location
    Elsewhere
    Posts
    89

    Default

    Thanks a lot for this benchmarking, Michael. As a Gentoo user I know what to do.

    But something must be done about the horrible assortments of colours, e.g. whenever red is used. I am aware (from other threads) it looks easier said than done but the current color assortment really impairs reading those graphs.

  10. #20
    Join Date
    Jul 2012
    Posts
    138

    Default I'd love to see mor in-depth tests.

    These tests oftne land in "Meh, whatever" category, at least for me.

    I would like to see more thought-out in-depth tests.

    For example, whole point fo using gcc-4.7x for me is -flto optimisation.

    It would be nice to see what it can bring to the table when compiling programs from many sources and compilation units which are then linked into final library and/or executeable.

    Of course, right programm to test this is not something like tar but something more complex.

    Also it would be nice to see and compare used resources and final result during flto compilation and linking. flto has been notorious for eating memory and CPU cycles when compiling chrome or openoffice. It would be nice to see how much has this impact with gcc-4.5* - gcc-4.8*

    Also, when finding regressions, it would be nice to go in-depth for their cause. Is error on the part of compiler, or simply program infrastructure misunderstood some compilers new feature, for example ?

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
  •