LLVM Clang 16 vs. GCC 13 Compiler Performance On Intel Raptor Lake

[hubicka]

When comparing performance of shared libraries one need to use -fno-semantic-interposition to get apples-to-apples comparsions between GCC and LLVM since LLVM ignored ELF interposition rules.

Compiling the following with -O2 -fpic:

int ret1()
{
return 1;
}
int test()
{
return ret1();
}


LLVM will optimize test to:

test:
movl $1, %eax
retq

which assumes that one never interposes ret1 with different implementation. GCC keeps the call:

test:
xorl %eax, %eax
jmp ret1@PLT

and only optimizes it with -O2 -fpic -fno-semantic-interposition. This can make a lot of performance difference.

[brad0]

Wow, Clang has come a long way. Just a couple of years ago Clang was decimated in some of these benchmarks.
👏👏👏

An extremely small sum of some.

Not surprising when everyone under the sun is using Clang nowadays.

[ryao]

LLVM is not Clang, it's the base for Clang and other compilers like Swift, Rust etc..

I worked on Clang tooling, so I could see the engagement of Google. Why do you think Clang was falling behind GCC?

https://en.cppreference.com/w/cpp/compiler_support#cpp20

Look at modules or coroutines, they are still not finished. Clang was for a time the best compiler but in the last time it shows quality issues. It has little glitches but they are annoying. MSVC actually got much better. GCC stayed steady. But that is only my personal expirience as a C++ developer.

Having support for the latest C++ language version is not a great metric for deciding what the best compiler is. Things like the quality and correctness of code generation and the quality of diagnostics matter far more.

Also, Clang is adding support at a decent pace. It is not like MSVC, which took around 20 years to support C99. If you are not happy with it ge implementation speed, you could contribute patches to speed things up.

When comparing performance of shared libraries one need to use -fno-semantic-interposition to get apples-to-apples comparsions between GCC and LLVM since LLVM ignored ELF interposition rules.

Compiling the following with -O2 -fpic:

int ret1()
{
return 1;
}
int test()
{
return ret1();
}


LLVM will optimize test to:


which assumes that one never interposes ret1 with different implementation. GCC keeps the call:



and only optimizes it with -O2 -fpic -fno-semantic-interposition. This can make a lot of performance difference.

Different compilers make different choices for what optimization levels mean. If GCC’s developers do not want to enable optimizations as part of them, then it is fair to let benchmarks reflect that.

[patrick1946]

Having support for the latest C++ language version is not a great metric for deciding what the best compiler is. Things like the quality and correctness of code generation and the quality of diagnostics matter far more.

It maybe matter for you but for me fixing some of the biggest deficits of C++ matter more for me. I not even see a big difference in quality of diagnostics. GCC got much better.

Also, is adding support at a decent pace. It is not like MSVC, which took around 20 years to support C99. If you are not happy with it ge implementation speed, you could contribute patches to speed things up.

I don't program C, so I don't care. And I don't do unpaid work. I simply described my daily impressions and I think it is not very productive to argue what tool is 'best but which is the most useful for a specific task.

Different compilers make different choices for what optimization levels mean. If GCC’s developers do not want to enable optimizations as part of them, then it is fair to let benchmarks reflect that.

You can argue about optimizations. I argue about language features which makes it easier to write performant and maintainable code. So I think there is no point in argumentation here. ;-)

[Setif]

LLVM is not Clang, it's the base for Clang and other compilers like Swift, Rust etc..

I was referring to LLVM as project.

[DanglingPointer]

Would be good to see 12.2 vs 12.3 vs 13.1 vs llvm-15 vs llvm-16
with:

• O2
• O3
• O2 -flto
• O3 -flto
• O3 -flto=thin (llvm)
• march=native O2
• march=native O3
• march=native O2 -flto
• march=native O3 -flto
• march=native O3 -flto=thin (llvm)

with AMD

[mlau]

When comparing performance of shared libraries one need to use -fno-semantic-interposition to get apples-to-apples comparsions between GCC and LLVM since LLVM ignored ELF interposition rules.

Does anything in the greater ELF ecosystem depend on -fsemantic-interposition being default? Would making "ret1()" static make a difference?
From my naive application developer point of view, the clang behavior seems to be more in line of what I'd like the compiler to do.

[discordian]

When comparing performance of shared libraries one need to use -fno-semantic-interposition to get apples-to-apples comparsions between GCC and LLVM since LLVM ignored ELF interposition rules.

Compiling the following with -O2 -fpic:

int ret1()
{
return 1;
}
int test()
{
return ret1();
}


LLVM will optimize test to:


which assumes that one never interposes ret1 with different implementation. GCC keeps the call:

if visibility defaults to "hidden" then that is a fair assumption.

and only optimizes it with -O2 -fpic -fno-semantic-interposition. This can make a lot of performance difference.

`-fno-semantic-interposition` should only affect calls to functions without definition - functions with definition and visibility=hidden (nowadays the default) are internal implementation details and should not be exposed.

TBH this whole ELF interposition should've never been the default but an explicit opt-in. Its not used anywhere outside of hooking stuff into libc

[carewolf]

So the libjxl got compiled with -O2 for gcc, and -O3 for clang?.. And why use -O3 -march=native -O2 on gcc? It seems the last -O2 is a bug.

[CochainComplex]

Is Clear Linux shifting to clang for some binaries ?