Hacker News new | ask | show | jobs
by dnautics 6 days ago
> some builtins purport to work on simd vectors but actually just unpack the vectors and do their work per-element (e.g. running `@sin()` on a `@Vector(4, f32)` will unpack the vector, run `@sin()` 4 times, and then pack it back into a vector).

this is reasonable because there isn't really a generalizable "good way" to unroll trig functions for simd. if you really care about speed youre better off implementing to the precision you care about (you might not want full precision)
5 comments
AlotOfReading 6 days ago
The loop dependency on a poly isn't all that hard for compilers to unroll, and most correctly rounded implementations are polys. You're often paying only a couple cycles' worth of stalls.

We can see this in action. LLVM implements sin() with a correctly rounded double poly [0]. Let's ignore range reduction and throw the core into compiler explorer to be autovectorized [1]. uiCA estimates a theoretical latency for the inner loop of 15 cycles, and the code achieves 18.

I suspect most custom implementations would do worse than this.

[0] https://github.com/llvm/llvm-project/blob/165c472d65cd62eb33...

[1] https://godbolt.org/z/rGGq8aG38

link
wrl 6 days ago
i don't disagree – i have my own internal vector lib of approximations and whatnot for various tradeoffs of precision and speed, so i just use those. it's just that zig has a pretty strong stance of "no unexpected/obscured code execution" so it was surprising to see a vector-capable function that was just a bunch of scalar functions in a trench coat.

maybe functions that don't actually support actual vector execution just shouldn't work on vector arguments. i also wouldn't expect `@sin()` to expand in-place out to a full cephes-like sin implementation. maybe a function call.

link
dnautics 5 days ago
> maybe functions that don't actually support actual vector execution just shouldn't work on vector arguments.

i think that's reasonable.

link
BoingBoomTschak 6 days ago
https://sourceware.org/glibc/wiki/libmvec ?
link
fancyfredbot 6 days ago
I bet there's a better way than unpacking, running sequentially and repacking. Even if the algorithm is very branchy you save a pack and unpack.
link
dnautics 5 days ago
"better" - for whom? will it cause problems if, for example you are writing scientific code?
link
inigyou 6 days ago
Why isn't there? It's usually just a bunch of math and short branching that can be replaced with masks.
link