Announcement

Collapse
No announcement yet.

Benchmarking GCC 4.2 Through GCC 4.8 On AMD & Intel Hardware

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

  • #11
    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

    Comment


    • #12
      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...

      Comment


      • #13
        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.

        Comment


        • #14
          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.

          Comment


          • #15
            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?

            Comment


            • #16
              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).

              Comment


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

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

                Comment


                • #18
                  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.)

                  Comment


                  • #19
                    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.

                    Comment


                    • #20
                      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 ?

                      Comment

                      Working...
                      X