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

[carewolf]

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.

And overall those changes were statistically insignificant before being cherry-picked...

[andyprough]

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?

But if GCC and Clang are crossing the street together, hand-in-hand, and both are hit by the same bus at the same time, then there's a big problem. Which is why we need to re-write the kernel in rust as quickly as possible.

[DanglingPointer]

LLVM Clang and LLD has matured nicely with the kernel. But what has not is the bloody DKMS! If you now try and run Virtualbox guests on a host built using llvm clang and lld with flto=thin, then DKMS modules don't build correctly or at all without jumping through hoops!

This needs to get fixed otherwise it will continue to impede adoption of this rapidly evolving build tool!

[GruenSein]

And overall those changes were statistically insignificant before being cherry-picked...

Overall, yes. But hardly anyone frequently runs a broad spectrum of benchmarks as the main use of his or her computer. Most people have few workflows they do over and over again. What this benchmark series and the following selection shows is that IF there is a difference in performance, the results are largely in favor of clang. This is something global averages do not tell you. It might very well be the case that overall differences are insignificant but on a case by case bases there might be an enormous back and forth between the compiler options. By filtering the results with virtually no difference, you get a much clearer picture of what to expect performancewise

[andyprough]

Overall, yes. But hardly anyone frequently runs a broad spectrum of benchmarks as the main use of his or her computer. Most people have few workflows they do over and over again. What this benchmark series and the following selection shows is that IF there is a difference in performance, the results are largely in favor of clang. This is something global averages do not tell you. It might very well be the case that overall differences are insignificant but on a case by case bases there might be an enormous back and forth between the compiler options. By filtering the results with virtually no difference, you get a much clearer picture of what to expect performancewise

If there was virtually no difference on all the tests where GCC won, then the final results of all 132 tests would have been lop-sided in Clang's favor. Clearly the GCC wins counter-balanced the large Clang wins.

[ktecho]

Do you know if there is a way to test this easily in Ubuntu? Is there some PPA?

[BesiegedAce]

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".

Except Michael posted both the results of all tests and then the 'statistically significant' ones. It's not like he hid anything, the data is all still there.

[CommunityMember]

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

You continue to spread the unsubstantiated rumor that LLVM is somehow broken or evil. If you have any evidence of such, please post it to LKML and have the ability to use LLVM removed from the kernel entirely.

[CochainComplex]

But if GCC and Clang are crossing the street together, hand-in-hand, and both are hit by the same bus at the same time, then there's a big problem. Which is why we need to re-write the kernel in rust as quickly as possible.

If we are already nitpicking.....it is quite unlikely that BOTH will cross the street and the same bus will kill them

Michael thx for the benchmark. Very interesting results.

[sdack]

Thanks for the benchmarks. These were interesting to see.

Perhaps it is too early, but what most people thought could happen one day might be just around the corner now. Clang might finally surpass GCC as leading compiler. GCC seems to suffer from regressions when compared to its previous versions, and thereby might be handing the lead over to Clang now. It may not be the way one wants to see a change in leadership happen, but one has to speculate if the age of GCC, and with it the cost of maintaining it, is finally getting too much. If so, then one has to speculate about how this impacts the code quality, too. So it is very interesting to see and to keep an open mind about it.