Announcement

Collapse
No announcement yet.

GCC 5.0 Doesn't Show Much Difference Yet For AMD's Steamroller

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

  • GCC 5.0 Doesn't Show Much Difference Yet For AMD's Steamroller

    Phoronix: GCC 5.0 Doesn't Show Much Difference Yet For AMD's Steamroller

    There's been a lot of AMD APU tests this week on Phoronix with having the newest Kaveri APUs. Our latest APU adventure is seeing how well the GCC performance compares between GCC 4.9 and GCC 4.10, what's expected to become GCC 5.0...

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

  • #2
    Originally posted by phoronix View Post
    Overall there isn't too much to get excited about with these GCC 4.9 vs. 4.10 compiler benchmarks
    6.5% faster in the 1st benchmark, 7.7% in the 2nd benchmark, 2% faster in the 3rd... not that bad. Only the last benchmark doesn't look that good for GCC-5

    Comment


    • #3
      Originally posted by oleid View Post
      6.5% faster in the 1st benchmark, 7.7% in the 2nd benchmark, 2% faster in the 3rd... not that bad. Only the last benchmark doesn't look that good for GCC-5
      Look at the openbenchmarking.org result file, in the article they only showed the graphs that showed wins. Still it's pretty good.

      Comment


      • #4
        Also, this was without LTO.

        main attraction of 4.10 is that LTO was to be polished, both WRT to optimisations being done as well as memory useage and CPU time during compilation.

        Had he used LTO and done some profile guided optimisations, preferably with LTO-ed relevant libraires, gain might have been better.

        Comment


        • #5
          Originally posted by Brane215 View Post
          Also, this was without LTO.

          main attraction of 4.10 is that LTO was to be polished, both WRT to optimisations being done as well as memory useage and CPU time during compilation.

          Had he used LTO and done some profile guided optimisations, preferably with LTO-ed relevant libraires, gain might have been better.
          LTO, PGO, and HyperZ, any other performance tweaks

          Comment


          • #6
            I stopped updating GCC after version 4.7.

            All later releases generate super bloated code which usually runs slower than the one produced using GCC 4.7.4 or GCC 4.5.4.

            I cannot understand where GCC is headed to but hopefully Clang will catch up with GCC and then outstrip it.

            Comment


            • #7
              Originally posted by birdie View Post
              I stopped updating GCC after version 4.7.
              looks like you stopped taking your meds

              Comment


              • #8
                Originally posted by birdie View Post
                I stopped updating GCC after version 4.7.

                All later releases generate super bloated code which usually runs slower than the one produced using GCC 4.7.4 or GCC 4.5.4.

                I cannot understand where GCC is headed to but hopefully Clang will catch up with GCC and then outstrip it.
                asm intermediate dumps or didn't happen

                Comment


                • #9
                  Originally posted by pal666 View Post
                  looks like you stopped taking your meds
                  Pathetic GCC fanb0i.

                  Comment


                  • #10
                    4.7 branch was closed in June, have you tried to file bug reports for any of the open branches to try and get problems fixed?

                    Comment


                    • #11
                      I've been trying to compile one of my projects with gcc 4.9.1 in Arch, every time it produced wrong assembly which lead to the program crashing. Switched to clang, now everything works fine.

                      Comment


                      • #12
                        Originally posted by AnAkIn View Post
                        I've been trying to compile one of my projects with gcc 4.9.1 in Arch, every time it produced wrong assembly which lead to the program crashing. Switched to clang, now everything works fine.
                        If you program contains invalid code that can cause GCC to miscompile it is only a matter of time before issues will crop up with any compiler. Better fix your code than complain about compilers.

                        Rule of thumb: If you think you have spotted a compiler error. You should consider youself wrong and fix your code instead (With more than 10 years of experience with C++ I have found one compiler error in GCC, but suspected errors more than 10 times and been wrong in every case but once).

                        Comment


                        • #13
                          Originally posted by AnAkIn View Post
                          I've been trying to compile one of my projects with gcc 4.9.1 in Arch, every time it produced wrong assembly which lead to the program crashing. Switched to clang, now everything works fine.
                          gcc often generates wrong code and it can take long time to fix. You should report bug to https://gcc.gnu.org/bugzilla/

                          Comment


                          • #14
                            Originally posted by carewolf View Post
                            If you program contains invalid code that can cause GCC to miscompile it is only a matter of time before issues will crop up with any compiler. Better fix your code than complain about compilers.

                            Rule of thumb: If you think you have spotted a compiler error. You should consider youself wrong and fix your code instead (With more than 10 years of experience with C++ I have found one compiler error in GCC, but suspected errors more than 10 times and been wrong in every case but once).
                            The code is in Valve's Source SDK, which I need for my project, and there's nothing wrong with it, it's a pretty simple code. MSVC and Clang compiles it correctly. GCC used to compiles it correctly as well, just not the latest versions.

                            Comment


                            • #15
                              Originally posted by AnAkIn View Post
                              The code is in Valve's Source SDK, which I need for my project, and there's nothing wrong with it, it's a pretty simple code. MSVC and Clang compiles it correctly. GCC used to compiles it correctly as well, just not the latest versions.
                              It is entirely possible for widely used library code to have subtle bugs. Popular ones are aliasing bugs. Whenever there is a pointer cast, view it with the utmost suspicion. Sometimes library functions are misused, like using memcpy or strcpy that only sometimes overlaps. Or a local variable's address might be returned and used in its caller, which may work fine until a compiler decides to inline and reorder the entire function chain. Or in C++ code an exception might be thrown with a local pointer. That is never a good idea but it sometimes appears to work.

                              Things like that are why I always run my test sets against both the debug code with asserts and also the O3 profile optimized version.

                              To sum up: Just because some code has been used for a long time, and other compilers compile it correctly, does NOT mean that the code is correct.

                              Comment

                              Working...
                              X