It's said that compiling GNU tools and Linux kernel with
-O3 gcc optimization option will produce weird and funky bugs. Is it true? Has anyone tried it or is it just a hoax?
-O3 has several disadvantages:
- First of all it often produces slower code than
-Os. Sometimes it produces longer code due to loop unrolling which may be in fact slower due to worse cache performance of code.
- As it was said it sometimes produces wrong code. It may be either due to error in optimalization or error in code (like ignoring strict aliasing). As kernel code sometimes is and sometimes have to be 'smart' I'd say it is possible that some kernel developer made some error. I experienced various strange problems, like crashing of userspace utilities, when I compiled kernel with gcc 4.5 which at that point was stable. I still use gcc 4.4 for kernel and several selected userspace utilities due to various bugs. The same may apply for
- I don't think it offers much benefit for the Linux kernel. The kernel does not do heavy computations and in places it does, it is optimized with assembly.
-O3flag will not change the cost of context switching or speed of I/O. I don't think something like <0.1% speedup of overall performance is worth it.
Over the last 10 years I've been running multiple Gentoo systems with 1000+ packages using
-O3 -march=native globally and have yet to run into any of these mythical stability issues that
-O3 is supposed to have. Benchmarks of CPU intensive applications (like math/science apps) consistently show
-O3 to produce faster code, after all it would be pointless if it didn't. For a majority of desktop apps
CFLAGS don't matter much as much anyway since they are IO bound, but it matters a lot for server side stuff that is CPU bound.
Note that large chunks of the toolchain (glibc in particular) flat out don't compile if you change optimization levels. The build system is setup to ignore your -O preferences for these sections on most sane distros.
Simply put, certain fundamental library and OS features depend on the code actually doing what it says, not what would be faster in many cases. -fgcse-after-reload in particular (enabled by -O3) can cause odd issues.
-O3 uses some aggressive optimisations that are only safe if certain assumptions about register use, how stack frames are interacted with, and function reentrancy are true, and these assumptions are not guaranteed to be true in some code like the kernel especially when inline assembly is used (as it is in some very low level parts of the kernel and its driver modules).
Yeah, this an old thread, but actually, no one have answered the question, that is: "does it (the -O3 option) really produce bugs in real application?, does it ever occurred?"
Of course I'm relying on my own experience, because there's simply no other way. I'm referring to gcc starting from version 4.4 here.
There are 2 existing "myths" about the O3 level in gcc, but what is really strange, those myths can be found even in official statements published by really big software companies (I'm not going to list them here, for obvious reasons).
Myth#1: O3 produces bigger code, so it can't fit the cache memory, and therefore it will in fact run slower -> actually it's the O2 which generates bigger executable code without any significant benefits -> it is usually slower than O1 - but O3 is always faster, typically +20% or more, mainly thanks to vectorization.
Myth#2: O3 breaks the resulting executable code: Not really a myth: the O3 can break the code which is not written in the "O3" in mind. Or in other words: the O3 will damage programs which were never meant to be optimized by the gcc at the O3 level. This normally should have a lengthy explanation, but I'll try to make it as short as possible:
O3 is ALLWAYS generating correct code, but the problem is that the optimized code is faster - this WILL break programs with unresolved / never tested logic race conditions (especially multi-threaded applications, linux kernel is a perfect candidate for a victim in this case)
O2/O3 optimization levels have the "clever" functionality for eliminating "apparently" dead code ("apparently" never executed OR the code provides results which are "apparently" never used) - this can cause astonishing crashes in programs which otherwise run flawlessly with O1 optimization level.
"does it really produce bugs in real application(s)?"
Yes, it does: I had to add function attribute: attribute((optimize("O1"))) in some cases, to prevent "dumb" removal of the nested calls, while using the O3 optimization level in gcc.
While you can get away with using -O3 and other optimizations knobs on most applications (and it can result in speed improvements), I would hesitate to use such tweaks the kernel itself or on the tool chain required for building it (compiler, binutils, etc.).
Think about it: Is a 5% performance gain of the raid and ext3 subsystems worth system crashes or potential data loss and/or corruption?
Tweak all the knobs to want for that Quake port you're playing or the audio/video codecs you use for ripping your DVD collection to divx files. You'll likely see an improvement. Just don't mess w/ the kernel unless you have time to waste and data you can bear to lose.