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)
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.
Rust is experimenting with "portable SIMD": https://doc.rust-lang.org/std/simd/index.html
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):
https://www.godbolt.org/z/MW8WeYjGo
Not sure why Rust needs a lot of experimenting tbh, it's been in Clang since forever.
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.
https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaP...
Wow! At least for me this is by far the best, clearest and most useful quick intro to Rust I've seen.
To OP: having this jarring purple, combined with a dark background and dotted underline is really painful for my eyes
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.
Reminds me of Learn x the hard way series by Zedshaw
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)
To complete the TL;DR : the safe Rust code is at 97% the speed of the C code, if keeping manual vectorization.
No, the Rust code is at 97% of the RUNTIME of the C code (https://cliffle.com/p/dangerust/5/#evaluation) when keeping the manual vectorization.
To complete the completion of the TL;DR : the 95% safe Rust Code using auto vectorization is even slightly faster than the C code.
The 95% safe Rust Code does not use any auto-vectorization (https://cliffle.com/p/dangerust/5/nbody-5.rs)
Only the 100% Rust-safe implementation uses auto-vectorization and is at 0.73% of the RUNTIME of the C code. (https://cliffle.com/p/dangerust/6/#performance-evaluation)
*73%