LLVM Clang 16 vs. GCC 13 Compiler Performance On AMD 4th Gen EPYC "Genoa"

[phoronix]

Phoronix: LLVM Clang 16 vs. GCC 13 Compiler Performance On AMD 4th Gen EPYC "Genoa"

With the recent stable releases of LLVM's Clang 16 and GCC 13 compilers there is now initial AMD Zen 4 "znver4" support in these open-source compilers. Curious about the performance difference between these two compilers on the very newest AMD 4th Gen EPYC "Genoa" server processors, I ran some LLVM Clang 16.0 and GCC 13.1 benchmarks on the flagship EPYC 9654 2P Linux server.

https://www.phoronix.com/review/amd-znver4-gcc13-clang16

[carewolf]

Am I blind, or are there no compile time benchmarks this time?

[oleid]

So in the end it's a "benchmark your code to see what works best". At work I use clang for development and gcc for deployment. Mostly due to clang's faster compile time of c++ code. Diagnostics are mostly on par nowadays.

[rene]

So cool this Linux distribution now has a clang by default as sys-cc and clang lot the linux kernel on other supported architectures, ... https://www.youtube.com/watch?v=nLyUhEMwGws !

[filbo]

The 'Number Of First Place Finishes' chart uses two nicely offsetting colors. Please use those same colors for all the individual bar charts so it is more readily apparent which is which. (I do see that in this article, the two contenders always appear in the same order, but you don't always do it that way; and color hinting is an improvement in any case.)

Since this was nominally a test of '-march=znver4', it would be nice to see that explicitly tested vs. '-march=native'. It would also be sufficient to say in the text that you ran a few representative tests on each compiler and confirmed that the two are equivalent, as intended.

I'd also be quite curious to see the entire set of tests also run on both compilers with '-march=blended', or whatever is used these days to generate broadly operable output code.

Finally, in the final geometric mean chart, it would be very interesting to see a 'fastest' contender. This would be a fake run where each individual benchmark got the fastest score of any of the individual real contenders. 'Fastest' would be the 100% contender, reducing each of the other competitors to a somewhat smaller number showing what fraction of the overall fastest possible score it can deliver. This seems particularly interesting in cases like this, where the final geomean seems to show that they're quite close together, yet there are many individual tests where one or the other rockets ahead. Seeing real contenders with, say, 96% scores would tell you it isn't that important to pick and choose for each binary; real scores in the 80% range might indicate that you really *should* think about mix and match.

[DanglingPointer]

These tests need to be run against the versions underneath to compare whether it is worthwhile to invest on DevOps and CICD to change:

• gcc-11.4
• gcc-12.3
• clang-14
• clang-15

All of which are still clearly in much wider use than gcc-13 and clang-16. This would help adoption to newer versions if we know it actually is worthwhile to invest in the DevOps processes to switch to the new compilers sooner rather than organically later after much time has passed.

[Healer_LFG]

I'd also be quite curious to see the entire set of tests also run on both compilers with '-march=blended', or whatever is used these days to generate broadly operable output code

-march=x86-64
-march=x86-64-v2
-march=x86-64-v3
-march=x86-64-v4

All these are generic options for x86_64 processors. Each one supports a different minimum-requirement of certain instruction sets, but are backwards compatible. I.E, a CPU that supports -march=x86-64-v4 will compile just fine with -march=x86-64, albeit without the beneifits that newer instruction sets will bring.

[Lycanthropist]

I wonder how clang compares to a current MSVC compiler.

[carewolf]

So in the end it's a "benchmark your code to see what works best". At work I use clang for development and gcc for deployment. Mostly due to clang's faster compile time of c++ code. Diagnostics are mostly on par nowadays.

But clang isn't faster anymore. Hasn't been for years. Diagnostics is a mixed bag. Clang has a tendency to accept waay more illegal C++ than gcc, I think because they need to simulate both gcc and msvc, but it accepts anything, often without a warning, but its warnings are often better when they are issued.

[oleid]

But clang isn't faster anymore. Hasn't been for years.

It is in our codebase. Which is mostly C++. AFAIR it is also the case for phoronix benchmarks. It is, however, slower for plain C code.