3 ms·

I think the issue with your argument is their optimizations are brittle, due to the complex limitations needed to vectorize code, as well as subtle compiler lim

I think the issue with your argument is their optimizations are brittle, due to the complex limitations needed to vectorize code, as well as subtle compiler limitations. Their optimizations also do not necessarily carry across compilers. If you are in gamedev, and are targeting multiple platforms, with multiple CPU architectures and compiler vendors, and your game relies on a particular function being 20x faster than the scalar version, then failing to vectorize is a blocker bug. Imo due to this, autovectorization is more of a nice surprise than something you can rely on.

rerdavies 1y ago
It boils down to: does it take longer to verify that the compiler did the right thing on each platform/architecture/processor you're interested in than it does to write hand-coded assembler which will be tightly tuned to a specific processor, and will not have proper instruction scheduling anyway, because humans just cannot do that anymore (and would have to be done all over again anyway for next year's Gen 16 intel processors that now have 7-wide instruction decoding stages instead of 5-wide instruction coding stages. As for fragility, if it's an obvious candidate for a SIMD loop, all the compilers I have worked with so far will obviously auto-vectorize it. What pushed me to the point of no going back: checking to see how they were doing it and finding complete models for the complete execution pipelines of literally hundreds of processor, and realizing that the reason why their code does such good instruction scheduling was because they had a full model of the execution pipeline! In both GCC and Clang sources. How long has this stuff been around for? A decade and a half? Two? The Compiler Kiddies needed SOMETHING to keep them occupied and employed for 20 years. And auto-vectorization was it. A major industry-wide initiative, specifically to address compiler auto-vectorization. AMAZING stuff. (Well. That and continuous never-ending C++ standards. But a LOT of auto-vectorization. And instruction scheduling).

rerdavies 1y ago

It boils down to: does it take longer to verify that the compiler did the right thing on each platform/architecture/processor you're interested in than it does to write hand-coded assembler which will be tightly tuned to a specific processor, and will not have proper instruction scheduling anyway, because humans just cannot do that anymore (and would have to be done all over again anyway for next year's Gen 16 intel processors that now have 7-wide instruction decoding stages instead of 5-wide instruction coding stages. As for fragility, if it's an obvious candidate for a SIMD loop, all the compilers I have worked with so far will obviously auto-vectorize it. What pushed me to the point of no going back: checking to see how they were doing it and finding complete models for the complete execution pipelines of literally hundreds of processor, and realizing that the reason why their code does such good instruction scheduling was because they had a full model of the execution pipeline! In both GCC and Clang sources. How long has this stuff been around for? A decade and a half? Two? The Compiler Kiddies needed SOMETHING to keep them occupied and employed for 20 years. And auto-vectorization was it. A major industry-wide initiative, specifically to address compiler auto-vectorization. AMAZING stuff. (Well. That and continuous never-ending C++ standards. But a LOT of auto-vectorization. And instruction scheduling).