Announcement

Collapse
No announcement yet.

GCC 14 vs. LLVM Clang 18 Compiler Performance On Fedora 40

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

  • GCC 14 vs. LLVM Clang 18 Compiler Performance On Fedora 40

    Phoronix: GCC 14 vs. LLVM Clang 18 Compiler Performance On Fedora 40

    One of the leading-edge benefits of Fedora Linux is that it always ships with the most up-to-date open-source compiler toolchains at release. For their spring releases each year, it typically means shipping with a GCC compiler that isn't even officially released as stable yet. With this week's release of Fedora 40, it's shipping with GCC 14.0.1 as the development version that will culminate with the inaugural GCC 14 stable release in the coming weeks. Plus Fedora 40 has all of the other latest GNU toolchain components and then over on the LLVM side is with the current LLVM 18 stable series. For those curious how GCC 14 vs. LLVM Clang 18 performance is looking, here is a wide range of C/C++ benchmarks carried out on Fedora Workstation 40 using a System76 Thelio Major workstation powered by the Zen 4 AMD Ryzen Threadripper 7980X.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Not a lot of sense in comparing video codecs because they include hand written assembly for most important/heavy parts of processing, so the compiler's role is quite minimal.

    SMHasher SHA3-256 could be sped up on GCC a lot: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113235

    No fix is proposed just yet.

    Comment


    • #3
      SMHasher code is quite special, it would IMO make sense to manually unroll it in the source code or add pragma.

      Compared to last year some of issues were fixed, including jpegxl

      Martin Jambor and me just had talk on this https://suselabs.konference.cz/agenda
      It was recorded so eventually video will appear I believe.

      jpegxl cmake used to rewrite -O3 by -O2 which was hardcoded in release flags. I filled upstream PR, but I am not sure if phoronix picked up the new version yet.

      Comment


      • #4
        Also graphicmagick sharpen problem was fixed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110062

        Comment


        • #5
          Would be nice if open source game engines (e.g. ioquake3, iodoom3) and DXVK/vkd3d/Wine were part of the test suite.

          Comment


          • #6
            For the cases with significant differences, I can't find excuses for the slower compiler not attempting to fix the performance problems ...

            Comment


            • #7
              Originally posted by eszlari View Post
              Would be nice if open source game engines (e.g. ioquake3, iodoom3) and DXVK/vkd3d/Wine were part of the test suite.
              The vast majority of games are GPU bound, not CPU bound, and those that are CPU bound are normally just horribly coded, so there's no point comparing them.

              And even if you compare them, it'll be quite hard to apply the result to your system because everyone has a different GPU.

              Comment


              • #8
                Originally posted by vladpetric View Post
                For the cases with significant differences, I can't find excuses for the slower compiler not attempting to fix the performance problems ...
                You're right!
                I'm looking forward to seeing your PR

                Comment


                • #9
                  Originally posted by avis View Post

                  The vast majority of games are GPU bound, not CPU bound, and those that are CPU bound are normally just horribly coded, so there's no point comparing them.
                  Quake and Doom are not horribly coded nor are they entirely GPU bound. It is valid to use them as a test case.

                  Comment


                  • #10
                    Originally posted by Kjell View Post

                    You're right!
                    I'm looking forward to seeing your PR
                    I have filed performance bug reports a long time ago (for both gcc and clang) and they were more-or-less ignored. Kindly let me know if this time it'd be different ...

                    Comment

                    Working...
                    X