SIMD Vectors and `transmute`

help
1

Hi, I'm trying to learn about SIMD, and am quite confused about a lot of stuff. I have a few questions about SIMD and std::mem::transmute:

  1. When people call SIMD a compiler intrinsic does that mean that its like a "compile time abstraction" i.e. Simd<[T; N]> is the same as a [T; N] under the hood? The fact that you can transmute an array into a Simd suggests so, but I'm not very familiar with the transmute function.
  2. If I have an array of u32s, is there any benefit in storing them as a [Simd<[u32; N]>] rather than storing them simply as a [u32] and just transmuting when I need to calculate something? I assume if I were to store them as a [u32] I would have to pad the array to be a multiple of N.
  3. How can I work with Vec<u32>? Is the best way to just use slices or can I somehow convert it into a Vec<Simd<[u32; N]>>? As with the question above, is there any benefit in storing them as a Vec<Simd<[u32; N]>>?
  4. If I have an array of references (i.e. [&mut u32] (or Vec<&mut u32>)) can I perform SIMD calculations?
  5. I can't use SIMD with new types (e.g. Health(pub u32)) right?

I came across this blog post which suggests there is a benefit to storing things as a Simd. Thanks in advance for any answers.

2

The big question is alignment of data.

u32 only needs to be aligned to 4 bytes, but SIMD vectors typically require 16, or use of special instructions for unaligned reads.

If your Simd wrapper type has its own alignment requirements, then it's unsafe to transmute [u32] to [Simd<[u32; N]>].

Re 3: Transmuting of Vec is very hard and often impossible to get right, so work on slices instead. See align_to.

Re 4: [&mut u32] is absolutely awful for performance — you pay cost of indirection, likely cache misses, and the reference type is as large or larger than u32, so you're more than doubling your storage cost and halving memory bandwidth. You should strongly avoid it, even if you're not using SIMD.

Re 5: You can with appropriate alignment and #[repr(transparent)].

3

Thank you!