Announcement

Collapse
No announcement yet.

Squeezing More Performance Out Of The Linux Kernel With Clang + LTO

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

  • Squeezing More Performance Out Of The Linux Kernel With Clang + LTO

    Phoronix: Squeezing More Performance Out Of The Linux Kernel With Clang + LTO

    With the Linux 5.12 kernel bringing support for building the kernel with link-time optimizations (LTO) when using the LLVM Clang compiler, here are some benchmarks looking at that performance impact as well as more generally seeing how the LLVM Clang compiler performance is looking when building the Linux kernel relative to GCC.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    You dropped the results of 104 different tests in order to show a Clang+LTO lead????

    That is some strange statistical voodoo, Michael. The fact is, after 132 tests there is no statistically significant difference, and the miniscule difference you did find should be attributed to statistical noise.

    Comment


    • #3
      If reliability and trustability do not matter to you, build with LLVM, otherwise stick to GCC.

      Comment


      • #4
        OpenMandriva provide both kernels. One GCC and second build with Clang + LTO. Users can choose.

        Comment


        • #5
          Originally posted by Alexmitter View Post
          If reliability and trustability do not matter to you, build with LLVM, otherwise stick to GCC.
          Uhuh, I can also spread baseless FUD around without having to justify anything

          Comment


          • #6
            Originally posted by andyprough View Post
            You dropped the results of 104 different tests in order to show a Clang+LTO lead????

            That is some strange statistical voodoo, Michael. The fact is, after 132 tests there is no statistically significant difference, and the miniscule difference you did find should be attributed to statistical noise.
            You are wrongfully implying some sort of agenda here. While the overall difference is small due to the abundance of tests with small to no differences in performance, I for one find it helpful to know what the outcome is IF there is a difference. In theory, it could be 1000x faster in a single benchmark and 5x slower in some others and retain an overall advantage due to this single result. So, looking at the benchmarks which present significant differences in more detail is far from voodoo. It simply makes sense.

            Comment


            • #7
              Originally posted by GruenSein View Post

              You are wrongfully implying some sort of agenda here. While the overall difference is small due to the abundance of tests with small to no differences in performance, I for one find it helpful to know what the outcome is IF there is a difference. In theory, it could be 1000x faster in a single benchmark and 5x slower in some others and retain an overall advantage due to this single result. So, looking at the benchmarks which present significant differences in more detail is far from voodoo. It simply makes sense.
              Good, so you would have no problem with Michael setting aside 106 of the test results and only focusing on the 26 tests where GCC had a win, and changing the title of the article to "Squeezing More Performance Out Of The Linux Kernel With GCC".

              Comment


              • #8
                Originally posted by andyprough View Post

                Good, so you would have no problem with Michael setting aside 106 of the test results and only focusing on the 26 tests where GCC had a win, and changing the title of the article to "Squeezing More Performance Out Of The Linux Kernel With GCC".
                If the wins are trivial/non negligible (i.e. 0.1%) then yes you shouldn't have a problem with it.

                Comment


                • #9
                  People are missing the point. If GCC was hit by a bus tomorrow, there's still clang/LLVM to fall back on. How is that not a win?

                  Comment


                  • #10
                    Originally posted by andyprough View Post

                    Good, so you would have no problem with Michael setting aside 106 of the test results and only focusing on the 26 tests where GCC had a win, and changing the title of the article to "Squeezing More Performance Out Of The Linux Kernel With GCC".
                    Reread the article. Of course, picking results favoring only one compiler would misrepresent the performance. This is not what Michael did. He selected all results which showed significant differences, i.e., where people might care about the difference, irrespective of which configuration was the fastest. So the bottom line is: Most of the time, there is no real difference in compiler configurations for the Linux kernel but if there is one, the clang'd + LTO kernel is most likely faster.

                    Comment

                    Working...
                    X