AFAIK, auto-vectorization has the same limitation in Rust as in C and C++ - it cannot be required. Hence, it is very easy to break the vectorization in brittle ways, without even noticing the issue.
It would be nice to have a sort of autovec-or-error annotation for preventing this.
It defines a generic `Simd<T, N>` type, expressing "This is a vector of T elements (such as i8), and is present in chunks of N". Methods that are easily vectorisable are defined on it, so if you can express what you want to do with one, you'll get well defined vectorised operations. Maybe not as perfect as you could hand write if you know what you're doing, but it _does_ guarantee to use vector instructions, so you're not at the behest of the compiler recognising a loop idiom.
It's most likely built onto the same LLVM features which enable the 'Clang extended vector extension' for C (it even compiles down to scalar code for CPUs without SIMD support):
Just because the underlying infrastructure works doesn’t mean experimentation isn’t warranted, it’s about how you present the API to the user. Note that the ALI you’ve shown off here is different than the one shown above, maybe one or the other is better to use, hence experimenting with it.
Yes, that's a variant of manual vectorization. However, AFAIK Rust doesn't provide dynamic dispatching as part of the portable SIMD? If this is the case, ISPC still looks like a better option, I think, albeit it is unlikely to be seen as the Rusty way of doing things.
Clang emits a warning if you ask it to vectorize a loop and it can't; you can then promote that to an error. But even if the loop vectorizes, that doesn't mean that it vectorizes in the optimal way - my understanding is that pros write their loops with intrinsics specifying the operations they want for this reason.
If you learned Rust first but find yourself reading a lot of C then this is also a good thing to read because of the parallels it draws with the languages.
TL;DR: An introduction to Rust which starts with a Rust-unsafe C program, writing a Rust equivalent, then evolves it towards some of the higher-level abstractions in Rust.
(As opposed to the non-dangerous way which means writing safe code to begin with and mentioning unsafe as the exception)
It would be nice to have a sort of autovec-or-error annotation for preventing this.