GCC Benchmarks At Varying Optimization Levels With Core i9 10900K Show An Unexpected Surprise

[FPScholten]

I am using a custom Xanmod Linux kernel, when building the Linux kernel, it defaults to O2, wonder if I should forget about building it on GCC 10.2 (GCC 10.2 was just installed today from the Ubuntu toolchain ppa). I did not find any regression on using GCC 10.1 for building the Linux kernel.
But then I do build it optimised for my system (Haswell) so that might help.

[milkylainen]

Linus is going to shit all over (politely so) the GCC devs for releasing borked default optimization levels.
This is bad. Like really, really bad.

Popcorn time?

[mackal]

Wasn't there some talk about inliner changes for GCC 10 saying it would hurt -O2 performance or something?

[birdie]

Linus is going to shit all over (politely so) the GCC devs for releasing borked default optimization levels.
This is bad. Like really, really bad.

Popcorn time?

No one has tested kernel performance with GCC 10.2 yet, so it's too early to cry wolf.

[milkylainen]

No one has tested kernel performance with GCC 10.2 yet, so it's too early to cry wolf.

Well. Since the kernel is not a singular coherent piece of code, I find it unlikely that it's not going to be affected.
You have everything from straight & stupid managment code, cryptoloops, complex lookup, trees etc.
Sure, you won't find much float in the kernel, but nginx and postgres are pretty much integer.

But yeah. We'll have to wait and see.

[tildearrow]

Minor redundancies:

On Ubuntu 20.04 with the Linux 5.8 kernel the compilers GCC 8.4.0, GCC 9.3.0, and a GCC 10.2 snapshot from 10.2 were built from source while using the same build arguments across all tested builds and using the same compiler (Ubuntu 20.04 default compiler) for building these different GCC compiler releases.

Typo:

whcih may explain

Thank you for the benchmarks. I hereby refuse to upgrade to GCC 10 if -O2 is not going to have any effect.

[pyler]

https://lore.kernel.org/lkml/[email protected]/

[arQon]

https://lore.kernel.org/lkml/[email protected]/

That's a bit ironic. "The compiler devs have effed up O2, so we'll use O3 because we trust the compiler devs to have finally made that not generate code that's outright BROKEN rather than just non-performant"...

I don't think I've ever had code NOT break with O3. As in literally "ever". There's always been one or two files that had to be dropped to O2 even if the rest of the project worked.
(Hell, I've had code fail because of bugs in O*2* - the test suite caught them, but diagnosing root cause was a bitch!).

So I wish the kernel team luck - though, hmm, in fairness, their code IS far simpler (implicitly from language used) so he may well be right: the C compiler really SHOULD be past the point of screwing up at O3 these days, other than regressions. I still sure as hell wouldn't personally risk it on production code without a HUGE test suite in place though. :P

[ypnos]

I don't think I've ever had code NOT break with O3. As in literally "ever". There's always been one or two files that had to be dropped to O2 even if the rest of the project worked.
(Hell, I've had code fail because of bugs in O*2* - the test suite caught them, but diagnosing root cause was a bitch!).

Could you give some examples that illustrate your anecdote?
I'm really curious as I have developed my software exclusively with -O3 for about 10 years now and never ran into problems. Yes I stumbled upon one or the other GCC bug and even submitted bug reports but those were not optimization-related.

I know -O3 was considered dangerous in the past but that was like 15 years ago.

Btw. this is what Linus has to say: https://lore.kernel.org/lkml/CAHk-=w...ail.gmail.com/ (very much in the spirit of your post)

[IlPini]

Qualitatively looking for the low point dragging down the final geometric mean, I couldn't find it by skimming the graphs.
The text below the second one ("regressed the performance the most") doesn't agree with the graph itself.
Oh, got it: I see two identical copies of the first graph, "Crypto++ v8.2 - Test: All Algorithms".