Experimental -O3 Optimizing The Linux Kernel For Better Performance Brought Up Again

[sinepgib]

people with very weak PCs and that's it.

There's a lot of people matching this. But most of those don't know how to build a kernel so...

Re: optimizations, am I the only one who reads de un{safe,roll} flags as "fun safe" and "fun roll" and chuckles?

[birdie]

There's a lot of people matching this. But most of those don't know how to build a kernel so...

Re: optimizations, am I the only one who reads de un{safe,roll} flags as "fun safe" and "fun roll" and chuckles?

Weak PCs are bogged down even more by modern applications which basically don't work unless you have at least 6GB of RAM and a fast enough CPU, I'm talking about web browsers and modern web, Electron applications, etc. etc. etc. so the kernel performance itself is again pretty meaningless.

[DanielG]

To be honest, discussing this without even knowing what benefits (if any) -O3 would *really* bring is pretty pointless.

phoronix What about an article comparing benchmarks running on a kernel built with the default -O2 vs. one built with -O3?
Would be interesting to see if there even is a noticeable difference, and so, for what kind of workloads.
(Should probably be done with an AMD GPU, maybe their millions of lines of driver-code can benefit from more optimization?)

[Vistaus]

About time. I've been using -Ofast for more than three years now on pretty much anything I come across (apps, libraries, etc.) and I've yet to see anything break, so -O3 is the least they could do.

[birdie]

To be honest, discussing this without even knowing what benefits (if any) -O3 would *really* bring is pretty pointless.

phoronix What about an article comparing benchmarks running on a kernel built with the default -O2 vs. one built with -O3?
Would be interesting to see if there even is a noticeable difference, and so, for what kind of workloads.
(Should probably be done with an AMD GPU, maybe their millions of lines of driver-code can benefit from more optimization?)

Michael has run tests in the past but I'm too lazy to search for them. As far as I remember, outside of artificial workloads (like creating millions of threads, serving tens thousands of small web pages per second or using software encryption for sending/receiving network traffic), the O3 kernel is only slightly faster.

Placebo is a huge thing anyways, so you may as well compile your kernel with -O3

[oiaohm]

To be honest, discussing this without even knowing what benefits (if any) -O3 would *really* bring is pretty pointless.

phoronix What about an article comparing benchmarks running on a kernel built with the default -O2 vs. one built with -O3?
Would be interesting to see if there even is a noticeable difference, and so, for what kind of workloads.
(Should probably be done with an AMD GPU, maybe their millions of lines of driver-code can benefit from more optimization?)

ClearLinux the one done by intel has done benchmarks comparing -O2 and -O3 of gcc. They have also documented that you are playing dangerous game that -O3 looks only very slightly faster when in fact its hiding a few race conditions. There is a reason why the -O3 feature is still experimental. The question is at this stage will gcc and llvm -O3 change to be kernel friendly or will the kernel have flaged out areas against particular optimisations.

We are talking performance gains with the Linux kernel in the less than 0.5 percent range. Worst part had to pick from run to run error.

Placebo effect is horrible high with a -O2 vs -O3 kernel. Works for me is also horrible high with the -O3 caused race conditions with kernel space code.

This is the problem there is a major difference between the optimisations that are acceptable on user-space program code and what is acceptable for a OS kernel program code. Worst part is using a not acceptable optimisation on OS kernel code has habit of causing race conditions. Race conditions those horrible hard to detect and diagnose bugs.

Lot of ways working out what optimisations features are absolutely safe to move from -O3 to -O2 would be better.

[Jannik2099]

The 1% happens to be OS kernel code when it not bad code. Kernel code you have access to multi page table setups. Normal application you can only see 1 set of page tables. This does alter presumed. The result is to build a kernel with -O3 particular optimisations will need to be disabled in particular places.

Lot of ways there should be -O3 for kernel code. Switching between user-space and kernel space page tables and interfacing with with memory across multi groups of page table this is behavour of protected mode OS kernels and fairly much nothing else.

Yes 1% good code with -O3 causing issues turns out be 99% focused to OS kernel building. Horrible part these are race conditions as well so you can have a lot of works for me when the build is in fact completely broken just you don't know yet.

-O2 for the Linux kernel is the safe choice. -O3 for Linux kernel is minor-ally unsafe the build might be totally fine but it could also be broken and -Ofast with Linux kernel is danger diving because something will be wrong somewhere.

Most of options current enabled for -03 that should be harmless to build the Linux kernel with. Problem here its not all options in -O3 are safe.

No, the 1% is absolutely not OS code, and certainly not something with as much code rot as the linux kernel.

Paging has absolutely nothing to do with this. It's neither required nor specially treated in the C standard, nor is there a magic -funsafe-paging flag in -O3 - it has absolutely nothing to do with the kind of UB that gets exposed by O3

Again, if O3 breaks something that means YOU have a bug. And that bug WILL most likely manifest at O2 too at some point in time. Ignoring the issue because you don't want to fix it does not help.

And again, no, all options in O3 ARE safe. All options in O3 are fully standards compliant in gcc and clang.

[DanielG]

Standards-compliant is uninteresting. You can't even implement memmove() with standards-compliant code, much less a kernel..

[Jannik2099]

Standards-compliant is uninteresting. You can't even implement memmove() with standards-compliant code, much less a kernel..

I'm not sure why people keep repeating this nonsense, but you totally can. You can also implement things like MMIO without any UB.

UB is needed around a few (very few) corners in a kernel context. It is not needed in remotely as many cases as are currently in the kernel.

[CommunityMember]

It's beyond time. O3 consists solely of safe, standards compliant optimizations on gcc and clang. The myth that O3 "has dangerous experimental optimizations" is just a legend from the gcc 4 era.

I have sometimes wondered why at least some distros appear to compile gcc itself with -O2, and not -O3? Do the package maintainers (who either are members of, or have contacts in, the gcc community) have good reasons to not select -O3 for their own tooling?