Announcement

Collapse
No announcement yet.

GCC 9.0 Compiler Benchmarks Against GCC7/GCC8 At The End Of 2018

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

  • GCC 9.0 Compiler Benchmarks Against GCC7/GCC8 At The End Of 2018

    Phoronix: GCC 9.0 Compiler Benchmarks Against GCC7/GCC8 At The End Of 2018

    In early 2019 we will see the first stable release of GCC 9 as the annual update to the GNU Compiler Collection that is bringing the D language front-end, more C2X and C++ additions, various microarchitecture optimizations from better Znver1 support to Icelake, and a range of other additions we'll provide a convenient recap of shortly. But for those wondering how the GCC 9 performance is looking, here are some fresh benchmarks when benchmarking the latest daily GCC 9.0 compiler against GCC 7.4 and GCC 8.2 atop Clear Linux using an Intel Core i9 7980XE Skylake-X system.

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

  • #2
    DAV1D benchmarks? Cool but can you use FPS instead of seconds, or at least specify the tested videos' lengths?

    Comment


    • #3
      Have GCC as a whole benefited by the switch from C to C++?

      Comment


      • #4
        I'm curious why O3 was picked and if the results would have the same with another one.

        Comment


        • #5
          Originally posted by Loranga View Post
          Have GCC as a whole benefited by the switch from C to C++?
          In terms of performance? Obviously no.

          Comment


          • #6
            What can explain those improvements in most benchmarks? I haven't been able to find out.

            Comment


            • #7
              Originally posted by Weasel View Post
              In terms of performance? Obviously no.
              Or obviously yes.

              By switching from several subtly different sets of hand-rolled text macros emitting C to a single implementation of code using C++, there are many opportunities for sophisticated compiler-driven optimizations that were not possible before the change.

              More importantly, though, the code is easier to understand. That makes it easier to maintain, less bug-prone, and better able to be extended with more sophisticated algorithms with greatly reduced effort.

              Comment


              • #8
                Originally posted by bregma View Post

                Or obviously yes.

                By switching from several subtly different sets of hand-rolled text macros emitting C to a single implementation of code using C++, there are many opportunities for sophisticated compiler-driven optimizations that were not possible before the change.

                More importantly, though, the code is easier to understand. That makes it easier to maintain, less bug-prone, and better able to be extended with more sophisticated algorithms with greatly reduced effort.
                You have some example or an link to a article with a more profound discussion of those changes? Thanks!

                Comment


                • #9
                  Originally posted by bregma View Post
                  Or obviously yes.
                  Or obviously no, as I said.

                  Originally posted by bregma View Post
                  By switching from several subtly different sets of hand-rolled text macros
                  It still uses a lot of "hand-rolled text macros" and it has nothing to do with C++ so it sounds like you're one of those parrot monkeys just throwing random buzzwords around.

                  Originally posted by bregma View Post
                  to a single implementation of code using C++, there are many opportunities for sophisticated compiler-driven optimizations that were not possible before the change.
                  More blabla buzzwords that have no basis on reality.

                  Originally posted by bregma View Post
                  More importantly, though, the code is easier to understand.
                  In terms of performance. "Easier to understand", "easier to maintain", those mean exactly zero. Performance is not a subjective metric like those bullshit metrics.

                  Originally posted by bregma View Post
                  better able to be extended with more sophisticated algorithms with greatly reduced effort.
                  Algorithm implementation has about 0.1% to do with the language.

                  Comment


                  • #10
                    Weasel Do you have an actual point to make or opinion to share other than being obnoxious and rude? I wish you all the maintenance joy of performance-sensitive code that combines macro code-generation with conditional compilation as well as healthy amount of branching, and raw arrays and plenty of pointer manipulation everywhere, whether performance requires it or not

                    Comment

                    Working...
                    X