GCC 9 vs. Clang 8 C/C++ Compiler Performance On AMD Threadripper, Intel Core i9

[phoronix]

Phoronix: GCC 9 vs. Clang 8 C/C++ Compiler Performance On AMD Threadripper, Intel Core i9

Since the release of the GCC 9 stable compiler suite earlier this month we have begun firing up a number of compiler benchmarks for this annual feature update to the GNU Compiler Collection. For your viewing pleasure today is looking at the performance of GCC 8 against GCC 9 compared to LLVM Clang 8 as the latest release of this friendly open-source compiler competition. This GCC 8 vs. GCC 9 vs. Clang 8 C/C++ compiler benchmarking was done on an Intel Core i9 7980XE and AMD Ryzen Threadripper 2990WX high-end desktop/workstation systems.

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

[gamerk2]

Basically, Clang has some really bad benchmarks dragging it down, but is otherwise basically competitive (if not faster) then GCC.

[grigi]

You can say the same about GCC.

Either way, competition is good.

[xorbe]

In our experience, clang seems to chew through template code faster than gcc. We also have a corner case issue for gcc (yet to file bug) that turns 30 seconds into 30 minutes.

[hubicka]

In our experience, clang seems to chew through template code faster than gcc. We also have a corner case issue for gcc (yet to file bug) that turns 30 seconds into 30 minutes.

Testcase would be really welcome. I keep an eye on template heavy code performance (since I maintain inliner in GCC) and having more stand alone testcases would be good.
Compile time really depends on inlining decisions in these cases which may or may not translate to better code quality. Fine tuning compiler for this is hard.

[paulpach]

What is going on in MKL-DNN? is gcc hitting some particular corner case?

[SystemCrasher]

Well, for some workloads at least. In the case of compiling PHP, GCC compiled it faster than Clang.

So much for "it compiles faster, much faster" kind of marketing BS. As optimizations grown comparable, compile times either.

[xorbe]

Testcase would be really welcome. I keep an eye on template heavy code performance(since I maintain inliner in GCC) and having more stand alone testcases would be good.
Compile time really depends on inlining decisions in these cases which may or may not translate to better code quality. Fine tuning compiler for this is hard.

Hey hubicka, yes we are working on it. We have to non-nda it and then get a stamp of approval. Sadly it is dependent on size of input, so small input is fast, and large input exposes the O(n²) behavior. So it's a large code sample. Yeah it's template code.

[monohouse]

A large number of "improvements" to code generation have been made, including but not limited to the following.

• Inter-procedural optimization improvements:
  • Inliner defaults was tuned to better suits modern C++ codebases
• Profile driven optimization improvements:
  • -fprofile-use now enables -fversion-loops-for-strides, -floop-interchange, -floop-unroll-and-jam, -ftree-loop-distribution.
  • Streaming of counter histograms was removed. This reduces the size of profile files. Histogram is computed on the fly with link-time optimization.
• Link-time optimization improvements: Overal compile time of Firefox 66 and LibreOffice 6.2.3 on an 8 core machine was reduced by about 5% compared to GCC 8.3. Size of LTO object files is reduced by 7%. LTO link-time improves by 11% on 8-core machine and scales significantly better for more parallel build environments. Serial stage of the link-time optimization is 28% faster consuming 20% less memory. Parallel stage now partitions to 128 partitions rather than 32 and reduces memory use for every worker by 30%.
  • Types are now simplified prior streaming resulting in significant reductions of the LTO object files, link-time memory use, and improvements of link-time parallelism.

fellas don't be surprised that code runs slower, as you can see the GCC programmers decided to reduce code performance in exchange for compiling speed etc...
certainly removinghistograms could be made optional, same for the inliner modernizing and simplification of types for LTO too.

[rsgah]

I have inspected why clang gets much slower speed on c-ray-test. If we tune clang's inline threshold, we might get closer result as gcc.