Matt Pharr (author of the SIMD programming language ISPC) nailed it with the insight "Auto-vectorization is not a programming model."
As Matt writes ([1]) : " The problem with an auto-vectorizer is that as long as vectorization can fail (and it will), then if you’re a programmer who actually cares about what code the compiler generates for your program, you must come to deeply understand the auto-vectorizer. Then, when it fails to vectorize code you want to be vectorized, you can either poke it in the right ways or change your program in the right ways so that it works for you again. This is a horrible way to program; it’s all alchemy and guesswork and you need to become deeply specialized about the nuances of a single compiler’s implementation—something you wouldn’t otherwise need to care about one bit."
I’m not sure I follow their point. By going with structs of arrays you’re already getting your max SIMD bandwidth 80% there even with the most naive implementations. Learning which math operations are hardware SIMDable gets you another 10%. It’s the last 10% where you rely on math expressions (eg. trig identities), restricted pointers, and ternary “masking magic” where the author may have a point.
A recent example: https://glouw.com/2026/08/14/Ensim5.html