LLVM Clang Achieves ~96% The Performance Of GCC On Intel Ice Lake

[phoronix]

Phoronix: LLVM Clang Achieves ~96% The Performance Of GCC On Intel Ice Lake

The LLVM Clang compiler continues becoming increasing competitive against the long-standing GNU Compiler Collection (GCC) on Linux x86_64 systems... With tests done on Intel Ice Lake using the Core i7-1065G7, the Clang 9.0 stable performance is delivering over 95% the performance of GCC 9 stable based on over 40 C/C++ benchmarks...

http://www.phoronix.com/scan.php?page=news_item&px=GCC-LLVM-Clang-Icelake-Tests

[milkylainen]

I'm surprised the Linux kernel takes that much longer to compile with Clang. It's slightly faster at compiling LLVM. So what gives?

[pyler]

Take out c-ray benchmark and geomean is changed, clang wins.

[nuetzel]

On Intel...

[sunnyflunk]

2 things stand out.

1. Lame favours GCC with its configure scripts by adding fflags such a -ffast-math which doesn't happen with Clang. Adding the flag could remove the performance difference. This is quite common where software is not tested with Clang (particularly upstream) and may impact more of the tests. Hopefully that changes now.
2. What build of Clang is being used? The builds included by distributions are rarely tuned for performance with LTO/PGO or a static Clang binary. Having a performance built Clang (matching the GCC build) can actually halve compile times in some instances.

Changing those 2 things alone (if 2 is valid) would probably turn the result around.

[lsatenstein]

I have been testing c code that I wrote with both GCC and CLANG. I run "strip executable" to remove unnecessary overhead such as debugging tables.
54k Code shrinks to 44K with GCC and strip the same code shrinks to 43k with CLANG using gcc9.2 and corresponding CLANG version.

I loaded Debian with a version 8 GCC and a back version of CLANG. 54k shrinks to 44k for GCC and 38K for clang. Both executables appear to execute at about the same speed. I suppose that different versions of strip are responsible for the difference in the sizes of the executables.

[pyler]

If Lame favours gcc, Michael should remove it from benchmark suite or patch build script.

[discordian]

If Lame favours gcc, Michael should remove it from benchmark suite or patch build script.

Depends on what you want to test. If you build stuff in the real world, it often happens that code is tuned to gcc/x86 and not tested anywhere else.
This starts from simple avoiding constructs gcc cant optimize well, to preprocessor and buildsystems checks.

So for real world results without tinkering, just a fair number of tests satisfy.

[c117152]

Depends on what you want to test. If you build stuff in the real world, it often happens that code is tuned to gcc/x86 and not tested anywhere else.
This starts from simple avoiding constructs gcc cant optimize well, to preprocessor and buildsystems checks.

So for real world results without tinkering, just a fair number of tests satisfy.

Seconded. These tests aspire to evaluate real world performance, not theoretical synthetic figures. LAME lacking LLVM related build flags reflects the state of the whole FOSS stack. The correct solution to the issue is for an LLVM distribution (the BSDs usually) to add the missing flags and upstream. Not to selectively pick and choose convenient benchmarks. LLVM can do their own marketing.

[pyler]

Lame is dead probably (last release two years ago)