Is it safe to use -O3 system-wide?

[Windmill]

I found a blog of a gentoo user that was saying that now -O3 can be used system wide except for a few packages which fails to build. The post was from 2013 so in the meantime gcc has evolved. But many guides say not to use it because can break many packages or slow them down instead of boosting them. SO is it safe to enable it in my make.conf?

[fedeliallalinea]

If you can distinguish compilation problems related to -O3 optimization from others you can try to enable it, otherwise isn't a good idea.
_________________
Questions are guaranteed in life; Answers aren't.

[NeddySeagoon]

Windmill,

-O3 enables some unsafe floating point optimisations to go faster.
If you don't care about floating point and you can deal with the breakage, give it a go.

The down side is (when it works) it makes the code bigger in an attempt to get it to execute faster.
It does this by aligning data structures for faster reading/writing, removing branch instruction by repeating code inside a loop etc.
This bigger code may not fit into the CPU cache, resulting in main memory accesses that are about 100x slower that the CPU level 3 cache.
There will even be cases of running several things at the same time where the working sets fit in the cache together with -O2 but not with -O3.

This 'cache thrashing', displacing the contents then rereading from 100x slower RAM can result in slower execution.
You won't know unless you benchmark.

Conversely -Os can make things run faster for exactly the same reason that -O3 can make them slower.
More fits in the CPU cache and slow main memory operations are avoided.

What is good for some things is bad for others. It all depends on your real world workload.
If most of your workload is keyboard input bound, even if you build the apps with -O3, they will only be waiting longer between keystrokes.

Some packages set -O3 in the build systems. That's enough for me.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[Akkara]

-O3 is like a spicy hot pepper. Wonderfully flavorful when applied in the right amount to the right dishes, but can ruin things when used indiscriminantly.

It is a very aggressive optimizer. Appropriate for the innermost of inner loops - those dozens to 100s instructions where 50%+ of the time is being spent. Graphics rendering, Fourier transform, linear algebra, numerical solvers, pattern-matching, sorting, hashing, and crypto all come to mind.

Most packages make calls to specialized libraries when it needs such functions. It doesn't usually implement them itself, except when that package is the library. So optimizing most packages isn't likely to improve things further unless the package itself is performing the hard work. And even then, only a small portion of the code is involved. Most code typically handles non-critical data structures and UI logic. Those kinds of operations don't have a long enough string of predictable-access instructions for an optimizer to chew on and improve much. There's simply not enough "meat" in between the if-branches and calls to other functions.

What ends up happening, is the initializations - which often do have predictable sequences - get optimized heavily and run really fast. But it doesn't matter how fast the command-line options are parsed or how quickly it nulls out some hash table. All that does is make the code bigger. Which means it loads slower, needs more RAM, and overall taxes the resources more, without much gain, often a few % loss.

Even worse, if -ftree-vectorize is in use (I don't recall if -O3 enabled it when I ran these experiments ~5 yeas back), and data-structure alignment can't be determined, it'll generate several versions of the same code along with conditionals to test the addresses coming in and pick the most appropriate one to use. I had to write code very carefully and pepper it liberally with __aligns and #pragmas to get some linear-predictive encoders to optimize well. Meanwhile the "fill array with constant" function optimized readily and bloated from a ~16 byte function to nearly 1/2-KB - except that function was essentially irrelevant since it was almost never used.

Overall, I have found that -Os is a much more effective flag to use globally. Then, go thru the packages and apply per-package flags: Anything with 'lib' in the name can probably benefit from -O2. Libraries that involve mostly net access probably want to stay at -Os. A few select libraries (fftw, internal gtk rendering routines, and so on) might benefit from -O3. But in those cases, if it makes a big difference, the build system has often already been set up to apply the flags automatically. And if you happen to find one that benefits from -O3 that doesn't automatically include it, you might want to report to upstream for possible inclusion in its configure scripts.
_________________
Many think that Dilbert is a comic. Unfortunately it is a documentary.

[Juippisi]

Yeah, been using -O3 for a long time now. I feel like packages that dont work with -O3 nowadays just strip that flag and use -O2 instead. There arent many of those.

Running Gnome here. Dont think Ive had any errors with -O3, but every system is different of course.

EDIT: Havent noticed any difference to -O2 system by the way...