Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Almindor
    replied
    Originally posted by FireBurn View Post
    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.

    Leave a comment:


  • Soul_keeper
    replied
    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 ?

    Leave a comment:


  • wizard69
    replied
    Originally posted by CommunityMember View Post
    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. .

    Leave a comment:


  • duby229
    replied
    Originally posted by FireBurn View Post
    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.

    Leave a comment:


  • Grinch
    replied
    Originally posted by Michael View Post
    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.

    Leave a comment:


  • Michael
    replied
    Originally posted by Grinch View Post
    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.

    Leave a comment:


  • Grinch
    replied
    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.

    Leave a comment:


  • pracedru
    replied
    Very impressive performance from the new kid.

    Leave a comment:


  • pyler
    replied
    If AOCC is based on LLVM 9 then yes

    Leave a comment:


  • StarterX4
    replied
    So, the kernel should be also possibe to be built by AOCC too?

    Leave a comment:

Working...
X