Announcement

Collapse
No announcement yet.

Building The Linux Kernel With LLVM's Clang Yields Comparable Performance

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

  • Building The Linux Kernel With LLVM's Clang Yields Comparable Performance

    Phoronix: Building The Linux Kernel With LLVM's Clang Yields Comparable Performance

    With the upstream Linux kernel nearly compatible with LLVM's Clang compiler as an alternative to using GCC, I benchmarked the latest "LLVMLinux" code that's the Linux kernel compiled under Clang with some out-of-tree patches to see how its performance compares to a conventionally built kernel with GCC 4.8.

    http://www.phoronix.com/vr.php?view=20492

  • #2
    Good for Clang, bravo to the devs.

    Comment


    • #3
      Why not compare both with a build of the kernel under icc? Last I knew, they still ensured that the kernel built with the Intel toolchain...

      Comment


      • #4
        A pointless comparison for one very important reason.

        For normal tasks the kernel uses very little CPU time so you won't feel the difference between different compilers, or between different optimization levels.

        One way to really test the compiler will be to, for instance, run x264 encoding using 16 threads when you only have 4 CPU cores.

        Another interesting way will be to test a throughput of a high speed L2TP connection - the kernel will be really stressed in this case.

        Actually I can think of a dozen of different ways to really test the kernel performance, but this article has none of them.

        Comment


        • #5
          Originally posted by birdie View Post
          A pointless comparison for one very important reason.

          For normal tasks the kernel uses very little CPU time so you won't feel the difference between different compilers, or between different optimization levels.

          One way to really test the compiler will be to, for instance, run x264 encoding using 16 threads when you only have 4 CPU cores.

          Another interesting way will be to test a throughput of a high speed L2TP connection - the kernel will be really stressed in this case.

          Actually I can think of a dozen of different ways to really test the kernel performance, but this article has none of them.
          I think if you`d see significant differences then it would mean something is really broken.
          The time spend in code for kernel switching processes is minimal (the switching itself is more expensive), its when, how often and the strategy involved that gives you measurable run time differences.

          Comment


          • #6
            Originally posted by birdie View Post
            A pointless comparison for one very important reason.

            For normal tasks the kernel uses very little CPU time so you won't feel the difference between different compilers, or between different optimization levels.

            One way to really test the compiler will be to, for instance, run x264 encoding using 16 threads when you only have 4 CPU cores.

            Another interesting way will be to test a throughput of a high speed L2TP connection - the kernel will be really stressed in this case.

            Actually I can think of a dozen of different ways to really test the kernel performance, but this article has none of them.
            Huh, are you claiming that a Phoronix compiler benchmark is flawed or somehow biased towards LLVM?!

            Comment


            • #7
              I miss numbers about the time it needs to compile a kernel with LLVM compared to GCC.

              Comment


              • #8
                Interesting benchmarks, but comparing not-yet released LLVM/Clang 3.5 to a GCC 4.8 which is already one release behind seems not very fair.

                Comparing Clang 3.4.1 to GCC 4.9.0 would have been at least fair, or Clang 3.5 to GCC 4.10.

                Comment


                • #9
                  Originally posted by Vim_User View Post
                  I miss numbers about the time it needs to compile a kernel with LLVM compared to GCC.
                  That's what I was looking for, the performance of the compiler itself. The resulting output is (ideally) expected to be very close to identical, but if the cost of the compile time varies greatly, there's little benefit to using the slower compiler.

                  Comment


                  • #10
                    Originally posted by caligula View Post
                    Huh, are you claiming that a Phoronix compiler benchmark is flawed or somehow biased towards LLVM?!
                    He never mentioned either GCC or LLVM. The test results show no measurable differences between the two compilers. So where the hell did you just pull that out of?

                    Comment


                    • #11
                      Originally posted by discordian View Post
                      I think if you`d see significant differences then it would mean something is really broken.
                      The time spend in code for kernel switching processes is minimal (the switching itself is more expensive), its when, how often and the strategy involved that gives you measurable run time differences.
                      Either you are extremely dumb, or you just know nil about the kernel.

                      Among other very CPU intensive things that the kernel does, are 1) Encryption (even AES can be stressful on CPUs which don't the circuitry/acceleration it, e.g. Intel Pentiums or Celerons) 2) Various sorting methods (can be very stressful when there are thousands of objects) 3) filtering 4) searching and many others.

                      Michael, does not test any of these things. For single threaded user space applications the kernel usually has zero impact.

                      Comment


                      • #12
                        Originally posted by birdie View Post
                        Either you are extremely dumb, or you just know nil about the kernel.

                        Among other very CPU intensive things that the kernel does, are 1) Encryption (even AES can be stressful on CPUs which don't the circuitry/acceleration it, e.g. Intel Pentiums or Celerons) 2) Various sorting methods (can be very stressful when there are thousands of objects) 3) filtering 4) searching and many others.
                        Encryption - would be either inline asm for hardware support or some tight loops
                        Sorting - Primary concern is the algorithm
                        Filtering - you mean network stack?
                        Searching - same as sorting.

                        I really doubt there would be any significant differences, at any rate more than within normal user-space apps, but feel free to prove me wrong.
                        Originally posted by birdie View Post
                        Michael, does not test any of these things. For single threaded user space applications the kernel usually has zero impact.
                        And barely more for threaded ones, like the example with x264 you suggested - the overhead thats spent in the kernel for choosing the next process is small.

                        If you`d really want to stress test youd have to set the scheduler intervall to ridiculous low values (and then the values would still be questionable).

                        I agree that the benchmark in the article is rather useless, but I dont expect any significant differences for the "kernel stuff" that the kernel is doing, for everything else you can do easier comparisons if you single it out .eg just run the test using the encryption code.

                        Comment


                        • #13
                          Originally posted by chithanh View Post
                          Interesting benchmarks, but comparing not-yet released LLVM/Clang 3.5 to a GCC 4.8 which is already one release behind seems not very fair.

                          Comparing Clang 3.4.1 to GCC 4.9.0 would have been at least fair, or Clang 3.5 to GCC 4.10.
                          Clang 3.5 had to be used due to how the LLVMLinux build scripts are setup.
                          Michael Larabel
                          http://www.michaellarabel.com/

                          Comment


                          • #14
                            Originally posted by Vim_User View Post
                            I miss numbers about the time it needs to compile a kernel with LLVM compared to GCC.
                            Unfortunately it's not straightforward comparing the build times until all the patches are mainlined and don't need to rely upon the LLVMLinux build scripts that also build their own Clang, etc.
                            Michael Larabel
                            http://www.michaellarabel.com/

                            Comment


                            • #15
                              Michael, where is evidence that first kernel is compiled with gcc-4.8 i don't see it ? In logs i see first kernel you use is one ubuntu mainline kernel http://kernel.ubuntu.com/~kernel-ppa.../v3.14-trusty/ and those are currently still builded against precise's toolchain which is gcc 4.6 .

                              Comment

                              Working...
                              X