Ringing In 2020 By Clang'ing The Linux 5.5 Kernel - Benchmarks Of GCC vs. Clang Built Kernels

[Grinch]

So are we seeing results of the actual Kernels here or the benchmark programs ? Because unless Michael used binaries built using the SAME compiler across these tests, we're not really benchmarking the kernels. If he, as I assume, ran the GCC built kernel against GCC built benchmark programs, and the Clang built Kernel against Clang built benchmark programs, the result likely has very little to do with the performance of the underlying kernel and just how well the respective compilers optimized said benchmarks.

[Michael]

So are we seeing results of the actual Kernels here or the benchmark programs ? Because unless Michael used binaries built using the SAME compiler across these tests, we're not really benchmarking the kernels. If he, as I assume, ran the GCC built kernel against GCC built benchmark programs, and the Clang built Kernel against Clang built benchmark programs, the result likely has very little to do with the performance of the underlying kernel and just how well the respective compilers optimized said benchmarks.

As said in the article, the only change is the kernel built by the different compilers. The compiler for the software under test isn't changing in this article.

[Grinch]

As said in the article, the only change is the kernel built by the different compilers. The compiler for the software under test isn't changing in this article.

Ah great, I missed that. Then I'd like to echo the request of someone else in this thread about a Clang+LTO kernel (assuming it compiles, IIRC someone stated that they had built using Clang LTO in some Phoronix thread), it would be really interesting to see if there is any measurable performance impact.

[duby229]

Would love to know the difference between compiling the kernel with ld.bfd and ld.lld linkers, ls LLVM's offering faster?

Might be interesting to see bfd32 vs bfd64 as well.

[wizard69]

While it was never, exactly, a competition, the friendly goal of being at least equal, if not better, than the other one, have managed to encourage improvements to both compilers to the point of essentially equivalent generated code performance. That has been a good result for all.

This is all true but I suspect the kernel source code is a big factor. There shouldn’t be a lot of opportunities in the kernel code as far as optimizations to take. That is there much that needs to compile in a way that leads to defined behavior

in any event this is great news. This should lead to higher quality code in the kernel repository. .

[Soul_keeper]

I just attempted this.
The clang binary ended up being about 5% smaller and boots fine.

The first issue i'm seeing is when I run clinfo
It goes defunct and dmesg shows the following:
[ 158.153940] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 158.153943] #PF: supervisor write access in kernel mode
[ 158.153944] #PF: error_code(0x0002) - not-present page
[ 158.153945] PGD f5f785067 P4D f5f785067 PUD fa86e1067 PMD 0
[ 158.153947] Oops: 0002 [#1] SMP
...
[ 158.153992] Fixing recursive fault but reboot is needed!
[ 275.310239] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 275.310242] #PF: supervisor write access in kernel mode
[ 275.310243] #PF: error_code(0x0002) - not-present page
[ 275.310243] PGD f54ea0067 P4D f54ea0067 PUD fce79a067 PMD 0
[ 275.310245] Oops: 0002 [#2] SMP
[ 275.310247] CPU: 13 PID: 2093 Comm: clinfo Tainted: G D 5.4.7 #7


Anyone else have this issue ?

[Almindor]

Would love to know the difference between compiling the kernel with ld.bfd and ld.lld linkers, ls LLVM's offering faster?

I've switched to ld.lld on all my Rust projects and it's a life saver on linking time. It's ~70% faster on non-trivial linkage. Not sure if it impacts any LTOs or such.