Live data from Hacker News

Rust SIMD on the GPU

vectorware.com

131–132 of 132 posts

Re: Rust SIMD on the GPU

#131
post #96

Earlier quoted context omitted.

> They specifies a constant SIMD width so it's non-portable. This is incorrect, you can use vectors wider than native SIMD width and the compiler will break them down to register size of the target cpu. In fact it's sometimes better to used wider than native width, in some applications I see 20% better throughput with f32x16 (512 bits) on an AVX2 CPU (256 bits). It is kinda like loop unrolling it.

Except you can't use this in actual code, because either, as is the case in this example with f32x32, you run out of registers and spill all over the place. Or you aren't using your full vector register or could've gotten better performance by "unrolling" more often for the larger vectors. If you use f32x16 (the avx-512 wisth), SSE now effectively has 4 registers to work with and will spill when doing anything beyond…

Your complaint is silly. Worst case the compiler copy pastes the code multiple times or adds a constant size for loop meaning the cost is negligible.

In the better cases it figures out how to reorder the instructions and gains performance over the naive implementation.

Re: Rust SIMD on the GPU

#132
post #97

Earlier quoted context omitted.

Counter question: why shouldn't it be portable? It's definitely a 80% solution where you occasionally need to drop down to intrinsics (at zero runtime perf cost) for CPU specific instructions. But just having vector types, arithmetic, swizzling, loads and stores will go a long way for basic tasks. And with generics you can write code that is type and width agnostic. No need to rewrite your code of you want to go from…

>Counter question: why shouldn't it be portable? Because there are platform vendors. And SIMD performance very much depends on the use-case, which is a balance of practicalities and specifications and intended deployment targets .. I also think this is a deployment problem, not a build problem, but okay ..

> also think this is a deployment problem, not a build problem ...

This I agree with, deploying and running code for the correct cpu is a problem with no established solution.

As for actually writing the code, portable_simd is great. You need to adjust simd width and compiler config for the cpu you deploy to and fill in the blanks with intrinsics. Which is much less work per target than writing it all with raw intrinsics if you are deploying to more than one target.

Post reply on HN