4 ms·
Vectorisation 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 I
by jleahy 5y ago
Vectorisation 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.