4 ms·
From my experience, -O2 includes optimizations that improve performance in the majority of cases. Whereas -O3 contains additional optimizations that may improve
by digitallyfree 5y ago
From my experience, -O2 includes optimizations that improve performance in the majority of cases. Whereas -O3 contains additional optimizations that may improve performance but the results are less clear-cut - hence why they're included in -O3 as opposed to -O2. I've seen cases where -O3 is faster than -O2, and vice versa.
- phkahler 5y agoThat's why its infuriating that vectorization was not enabled at -O2. Since x86-64 supports SSE2 as a baseline, every program has been under performing at -O2 for over 15 years. Without knowing this it turns out the recent introduction of -march=x86-64-v2 and v3 dont benefit either when both have AVX2 which goes largely unused. See pathetic test results here: https://github.com/solvespace/solvespace/issues/972 https://github.com/solvespace/solvespace/issues/972 Notice that v3 is no better and may even be a hair slower.
- gnufx 5y agoSee https://gcc.gnu.org/gcc-12/changes.html https://gcc.gnu.org/gcc-12/changes.html It's still not necessarily a guaranteed win, I think.
- jleahy 5y agoVectorisation is not a clear win, and so doesn’t belong in O2. Certainly it can deliver massive improvements in some cases (as loop unrolling could in Pentium III days), yet can cause significant binary size increases (think icache costs) and makes loops with small iteration counts potentially much slower. If for some reason you want O2 but with vectorisation you can enable it, and if you want O3 without inlining or loop unrolling (the same thing), you’re welcome to specify that.
- kzrdude 5y agoMaybe it could use a different heuristic in O2? Depending on the function it's vital to have autovectorization for performance. Neither -O3 nor -O2 are perfect as a blanket option for all the functions in a big program.
- userbinator 5y agoDid you mean the P4? An extremely long pipeline meant loop unrolling helps it far more than it does x86 processors before or after. PIII is more similar to Core/2/i in performance characteristics. ...and then there's Atom, which is also an odd one - I believe it's more like a classic Pentium (P54).
- jleahy 5y agoWell I did want to say the P4, but I never actually had one so didn’t want to say something that turned out to be wrong. Certainly on earlier microarchitectures it did help a lot more than it does now, and there were some nice wins on the PIII for it
- phkahler 5y agoThe fact that they are changing to include some vectorization options by default for -O2 suggests otherwise. In particular SLP vectorization should have been there all along. Every graphics library 2d and 3d defines vector classes that will easily go faster with the simplest vectorization. Arguments around code size have been largely irrelevant for quite some time, so long as performance increases. If I put on a tinfoil hat, I'd suspect Intel was at least an influence. They're the ones adding AVX, AVX2, 512 and providing their own compiler to take advantage of them, while crippling AMD parts. That is until they switched to LLVM.
- sroussey 5y agoCode size always matters. The code cache in the cpu is far from infinite and long jumps will stall. Sometimes vectorization can shrink code, so yay. And, like you said, if performance increases, then yay again regardless of size.
- ncmncm 5y agoCode size always matters, except for all the times when it doesn't. Or when something else matters more. Code size matters less than it once did, now that we have bigger and smarter caches. But bigger, while sometimes big enough, is never big.
- amelius 5y agoCan you turn on optimizations on a per-function basis?
- gnufx 5y agoYes, and that's sometimes a good idea. GCC has a pragma and function attribute (unfortunately not for Fortran, at least).