Fedora Stakeholders Debate Idea Of "-O3" Optimized Packages

[phoronix]

Phoronix: Fedora Stakeholders Debate Idea Of "-O3" Optimized Packages

Following the announcement yesterday that Ubuntu 25.04 will default to the -O3 optimization level with GCC for its Debian package builds, Fedora stakeholders have begun debating the merits of switching to the -O3 optimization level or not instead of the existing -O2 optimization level default...

https://www.phoronix.com/news/Fedora-Debates-O3-Packages

[Danny3]

That would be nice!
Similar to the AV1, HEVC codecs, the building process may be heavier for a few servers, but millions of end users will have benefits!
And with more optimized code, doiing things faster and finishing tasks sooner, there might be even power saving benefits, so smaller bills and environment pollution!
Looks like a great idea to me!

[avis]

TLDR: No.

/Thread

Long version: enable per package where a performance increase has actually been measured across at least a number of CPU architectures.

[jeisom]

They shouldn't. Little to no gain for most packages. If a maintainer finds that a specific package get noticeable gains, then they can do those, but I am not going to notice 'ls' finishing 0.1 seconds faster.

[patrick1946]

That would be nice!
Similar to the AV1, HEVC codecs, the building process may be heavier for a few servers, but millions of end users will have benefits!
And with more optimized code, doiing things faster and finishing tasks sooner, there might be even power saving benefits, so smaller bills and environment pollution!
Looks like a great idea to me!

Many package will be even slower because large code will spill the caches. PGO, LTO, etc. are much more promising. But that would be much more work.

[TheMightyBuzzard]

That would be nice!
Similar to the AV1, HEVC codecs, the building process may be heavier for a few servers, but millions of end users will have benefits!
And with more optimized code, doiing things faster and finishing tasks sooner, there might be even power saving benefits, so smaller bills and environment pollution!
Looks like a great idea to me!

Except -O3 in no way guarantees either more efficiency or more speed. It absolutely guarantees more power and cycles used during compiling as well as larger binary size though. So if your package is a memory hog rather than a CPU hog, it's even going to be a little counterproductive. For some packages it's worth testing, sure. For /bin/pwd though? For libjpeg? For a gazillion other things that would see no real world benefit but would most assuredly cost more time and power when it's distro building time? Nah. Do it on a package by package basis where it's actually useful.

[Espionage724]

I'm for it! Space I don't believe is a realistic issue: Most people run Flatpaks or likely have unused deps just lying around.

I'm for applying it everywhere: I trust it won't half-performance or something odd on a core service, and anything known-problematic I imagine can be weeded-out and re-O2'd

I'm not for individually applying O3 because "maintenance burden". Why would devs that could be working on something productive, be testing if their app is any faster or worthwhile with O3 if O2 is fine and O3 not enforced? Just do it everywhere, and fix the few things with issues afterwards.

The oldest machine I run Fedora on has a Phenom II X4; I'm mostly confident it can't be worse with O3, but I'll accept a minor hit if I get gains on my newer hardware.

Disclaimer: I don't know much about what O2 and O3 do realistically, but compiled stuff on my own machines with Ofast where possible because fast is surely faster since it's named!

[avis]

I'm for it! Space I don't believe is a realistic issue: Most people run Flatpaks or likely have unused deps just lying around.

I'm for applying it everywhere: I trust it won't half-performance or something odd on a core service, and anything known-problematic I imagine can be weeded-out and re-O2'd

I'm not for individually applying O3 because "maintenance burden". Why would devs that could be working on something productive, be testing if their app is any faster or worthwhile with O3 if O2 is fine and O3 not enforced? Just do it everywhere, and fix the few things with issues afterwards.

The oldest machine I run Fedora on has a Phenom II X4; I'm mostly confident it can't be worse with O3, but I'll accept a minor hit if I get gains on my newer hardware.

Disclaimer: I don't know much about what O2 and O3 do realistically, but compiled stuff on my own machines with Ofast where possible because fast is surely faster since it's named!

Most people run flatpaks? Really?

Here on Phoronix people were predominantly mad when Ubuntu made Chromium a snap.

I have exactly zero snaps/flatpaks/appimagines on my system and I intend not to have either in the future. And I know a lot of people who have gone to great lengths to reverse Ubuntu's packaging decisions.

[ms178]

I find it amusing and a little sad that a hobby project like CachyOS with very limited ressources does not shy away from the performance work to get a better distro to their users while Ubuntu and Red Hat are still debating if they want to use O3 for some time now. They got the compiler engineers, the CI, the build infrastructure or could afford to build up such efforts. But here we are in 2024.

[TheMightyBuzzard]

I'm for it! Space I don't believe is a realistic issue: Most people run Flatpaks or likely have unused deps just lying around.

I'm for applying it everywhere: I trust it won't half-performance or something odd on a core service, and anything known-problematic I imagine can be weeded-out and re-O2'd

I'm not for individually applying O3 because "maintenance burden". Why would devs that could be working on something productive, be testing if their app is any faster or worthwhile with O3 if O2 is fine and O3 not enforced? Just do it everywhere, and fix the few things with issues afterwards.

The oldest machine I run Fedora on has a Phenom II X4; I'm mostly confident it can't be worse with O3, but I'll accept a minor hit if I get gains on my newer hardware.

Disclaimer: I don't know much about what O2 and O3 do realistically, but compiled stuff on my own machines with Ofast where possible because fast is surely faster since it's named!

Man, I can't even tell how much of that is tongue-in-cheek. If that's all you trolling to wind folks who can answer up, I tip my hat to you. Well done.