4 ms·

I would at least appreciate a disclaimer that the vast majority of these optimizations could be accomplished by encouraging the compilers to make the assembly v

by kolbe 5y ago

I would at least appreciate a disclaimer that the vast majority of these optimizations could be accomplished by encouraging the compilers to make the assembly vectorized. You said in a footnote that compilers will only do these optimizations when they're extremely simple and rarely on integers, but I have not found that to be the case. -O3 and -mavx do an amazing job for most use cases. And more to the point, there are other tricks that I think it's better to turn to (like using the __restrict key word) before you take these fairly steep steps into coding the SIMD commands yourself. It's cool to learn these things. And it's down right important to learn these things once you're experienced enough, because you have to use them at some point if you're in the game of optimization. But also I would feel pretty bad if some kid out there wasted a week on a project at work (and got reprimanded for it) that could have been accomplished with a couple compiler flags, you know?

Const-me 5y ago
They’re getting better over time, especially for floats/doubles, but I still find them limited even for simple use cases. Here’s an example of auto-vectorizer in clang 12, which I believe represents state of the art at the moment: https://godbolt.org/z/6Pe33187W https://godbolt.org/z/6Pe33187W It automatically vectorized the loop and even manually unrolled it, however I think the code bottlenecks on shuffles not on memory loads. Just too many instructions in the loop, and that vpmovzxbq instruction can only run on port 5 on Skylake. Compare the assembly with manually vectorized version from an answer on stackoverflow: https://godbolt.org/z/do5e3- https://godbolt.org/z/do5e3-
janwas 5y ago
+1 for restrict, that certainly helps. Out of curiosity, what's your use case where autovectorization works well? Personally, I have often been disappointed. Not much progress in 2 years: http://www.0x80.pl/notesen/2021-01-18-autovectorization-gcc-clang.html http://www.0x80.pl/notesen/2021-01-18-autovectorization-gcc-...
- kolbe 5y ago
  I'll admit that there are times when I am both stunned at how well the compiler will optimize, and times when I'm stunned at how poorly it does. It would seem you can never make an assumption on what will happen--hence my addiction to godbolt. I don't have my exact code, but I work heavily with math operations, so it may be that I do encounter an especially easy types of loops to vectorize.
  - janwas 5y ago
    OK, that's fair. Godbolt is a great tool and autovectorization gets initial results quickly, but the price is eternal vigilance. Any compiler update/code maintenance risks falling on the wrong side of some compiler heuristic.
astrange 5y ago
Autovectorization is annoying and hard to work with because it's unpredictable. It also fights you if you manually vectorize - you can write a SIMD loop and scalar trailer loop, and then it'll autovectorize the trailer. If instead you wrote in an infinite-length vector language and the compiler scalarized it for you, I think that could work better.

by kolbe 5y ago

Const-me 5y ago

They’re getting better over time, especially for floats/doubles, but I still find them limited even for simple use cases. Here’s an example of auto-vectorizer in clang 12, which I believe represents state of the art at the moment: https://godbolt.org/z/6Pe33187W https://godbolt.org/z/6Pe33187W It automatically vectorized the loop and even manually unrolled it, however I think the code bottlenecks on shuffles not on memory loads. Just too many instructions in the loop, and that vpmovzxbq instruction can only run on port 5 on Skylake. Compare the assembly with manually vectorized version from an answer on stackoverflow: https://godbolt.org/z/do5e3- https://godbolt.org/z/do5e3-

janwas 5y ago

+1 for restrict, that certainly helps. Out of curiosity, what's your use case where autovectorization works well? Personally, I have often been disappointed. Not much progress in 2 years: http://www.0x80.pl/notesen/2021-01-18-autovectorization-gcc-clang.html http://www.0x80.pl/notesen/2021-01-18-autovectorization-gcc-...

kolbe 5y ago
I'll admit that there are times when I am both stunned at how well the compiler will optimize, and times when I'm stunned at how poorly it does. It would seem you can never make an assumption on what will happen--hence my addiction to godbolt. I don't have my exact code, but I work heavily with math operations, so it may be that I do encounter an especially easy types of loops to vectorize.
- janwas 5y ago
  OK, that's fair. Godbolt is a great tool and autovectorization gets initial results quickly, but the price is eternal vigilance. Any compiler update/code maintenance risks falling on the wrong side of some compiler heuristic.

astrange 5y ago

Autovectorization is annoying and hard to work with because it's unpredictable. It also fights you if you manually vectorize - you can write a SIMD loop and scalar trailer loop, and then it'll autovectorize the trailer. If instead you wrote in an infinite-length vector language and the compiler scalarized it for you, I think that could work better.