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

[phoronix]

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.

https://www.phoronix.com/review/gcc14-clang18-amd-zen4

[avis]

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.

[hubicka]

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849

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.

[hubicka]

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

[eszlari]

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

[vladpetric]

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

[avis]

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.

[Kjell]

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

[swastika]

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.

[vladpetric]

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 ...