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

[smitty3268]

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

IIRC that's a pretty bad benchmark. I believe it's just a matter of which compiler is tuned to inline functions more aggressively.

[CommunityMember]

... and upstream.

Some upstreams have been historically resistant to accepting flags, pragma options, or optimizations, on platforms they do not test on or target (and have no plans to test on or target). They consider that is for platform packagers to deal with. For a few major packages, there are entire teams that try to deal with the "portability" issues.

[kawa]

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.

My understanding is that this benchmark is using those projects as a way to measure the performance of the compiler. In that case, projects which specifically target a particular compiler - while they may be interesting curiosities - are inherently not portable and should not contribute to the result.

Also, "performance" can be measured in a variety of different ways. It would also be interesting to look at the resulting binary size.

[wizard69]

Very interesting results! CLang does amazingly well considering the resistance it often gets in the open source world. An investigation of the big delta such as C-ray would lead to a deeper understanding of what happened there.

[Quetzalcoatlus]

If GCC builds linux faster it's probably because Linux only ever officially supported GCC for a very long time if it doesn't still (been a while since i built my own kernel). I think not many people even attempt to build the kernel or modules with llvm due to the long history of weird compile errors and crashes happening when you build kernel space code with something not GCC even if that's not still much of an issue why take the chance when everything builds C fast.

I don't even care about runtime performance for anything I'm building myself, which isi typically in debug mode, since, if it's not an app with realtime graphics and it's maxing out a core, it's broken and needs debugging. Compile time performance, on the other hand, actually wastes my time whereas the CPU has plenty to spare, and llvm slays there so it's pretty much my default for building anything written in c++. But yeah I'm staying far far away from llvm-libc at the moment.

[rmoog]

[laffer1]

Some upstreams have been historically resistant to accepting flags, pragma options, or optimizations, on platforms they do not test on or target (and have no plans to test on or target). They consider that is for platform packagers to deal with. For a few major packages, there are entire teams that try to deal with the "portability" issues.

Very true. LLVM does this. They won't take upstream patches unless you can donate build infrastructure and a team to maintain it.

Getting patches upstreamed in the individual projects is probably the best way to even out the benchmarks. It might not be possible though.

[caligula]

Lame is dead probably (last release two years ago)

Why should there be? Mp3 is pretty old, nothing has changed. The core algorithms have stabilized. Take a look at ntfs-3g or some other mature package. No releases in recent years.

[Volta]

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

The same should be done with tests that favor Intel.

[Volta]

Very interesting results! CLang does amazingly well considering the resistance it often gets in the open source world. An investigation of the big delta such as C-ray would lead to a deeper understanding of what happened there.

Where do you see such resistance? You're delusional