3 ms·

i was having a conversation with a friend recently about simd in zig (which i have recently picked up and been having a pretty good time with). i find that simd

by wrl 2mo ago

i was having a conversation with a friend recently about simd in zig (which i have recently picked up and been having a pretty good time with). i find that simd writes decently well, though there's a few weird things: - 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). - a lot of `std.math` is scalar-only (some functions support vectors, though, and i've got a pr open for one of them and plan to do more). - i'm certainly missing some intrinsics that i get from xmmintrin.h (rcp, rsqrt, few others). in general though i'm finding it pretty capable. mitchell, i know you hang around some of these comments sometimes – i noticed that in ghostty you bring in some c++ libs to do the simd heavy lifting for you. any plans to port that to zig? anything missing from the language or libs that's preventing it?

mitchellh 2mo ago
> mitchell, i know you hang around some of these comments sometimes hi im here > i noticed that in ghostty you bring in some c++ libs to do the simd heavy lifting for you. any plans to port that to zig? anything missing from the language or libs that's preventing it? No plans to port it. For others, this is referencing highway: https://github.com/google/highway https://github.com/google/highway The major limitation of Zig's vectors is that they're compile-time only. So if you're building redistributed software that compiles for a baseline CPU target, it won't be as optimized as it could be for YOUR possible machine. Highway compiles our SIMD modules for different hardware configurations and at startup does a CPUID fingerprint to figure out which to load. That way even baseline has AVX512 etc. implementations, and we just activate the right one at runtime. We only use Highway for our hottest hot paths that we feel benefit from that specialization. No plans to port that (although, I spent hundreds of dollars and slop-forked it into Zig with the help of this good boy GPT and it worked great actually, but I didn't want to maintain it).
- wrl 2mo ago
  ahaaa, yeah, i don't personally do any runtime switching but i hear that as a deal-breaker from other folks. it's interesting – i've found that zig tends to extend my vectors to the native width of the platform and then operate on them there. e.g. i had a `@Vector(2, f32)` that i was using as a demo and the generated assembly was promoting it to 256 bits and using avx2 instructions on it!
  - mitchellh 2mo ago
    > i've found that zig tends to extend my vectors to the native width of the platform and then operate on them there oh interesting. though i suspect that isn't zig and thats llvm.
    - wrl 2mo ago
      looks like it – compiled as debug (native linux x64 backend) gives me the vector type i've asked for. release modes extend to the "native" width. this is testing in isolation as well, could be that in the midst of other vector code it changes things. llvm definitely does a great job optimising tightly-written vector code to be even faster.
- inigyou 2mo ago
  Why does your website block Tor so I can't read the article?
  - mitchellh 2mo ago
    No idea
dnautics 2mo 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)
- fancyfredbot 2mo 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.
  - dnautics 2mo ago
    "better" - for whom? will it cause problems if, for example you are writing scientific code?
- wrl 2mo 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.
  - dnautics 2mo ago
    > maybe functions that don't actually support actual vector execution just shouldn't work on vector arguments. i think that's reasonable.
- BoingBoomTschak 2mo ago
  https://sourceware.org/glibc/wiki/libmvec https://sourceware.org/glibc/wiki/libmvec ?

by wrl 2mo ago

mitchellh 2mo ago

> mitchell, i know you hang around some of these comments sometimes hi im here > i noticed that in ghostty you bring in some c++ libs to do the simd heavy lifting for you. any plans to port that to zig? anything missing from the language or libs that's preventing it? No plans to port it. For others, this is referencing highway: https://github.com/google/highway https://github.com/google/highway The major limitation of Zig's vectors is that they're compile-time only. So if you're building redistributed software that compiles for a baseline CPU target, it won't be as optimized as it could be for YOUR possible machine. Highway compiles our SIMD modules for different hardware configurations and at startup does a CPUID fingerprint to figure out which to load. That way even baseline has AVX512 etc. implementations, and we just activate the right one at runtime. We only use Highway for our hottest hot paths that we feel benefit from that specialization. No plans to port that (although, I spent hundreds of dollars and slop-forked it into Zig with the help of this good boy GPT and it worked great actually, but I didn't want to maintain it).

wrl 2mo ago
ahaaa, yeah, i don't personally do any runtime switching but i hear that as a deal-breaker from other folks. it's interesting – i've found that zig tends to extend my vectors to the native width of the platform and then operate on them there. e.g. i had a `@Vector(2, f32)` that i was using as a demo and the generated assembly was promoting it to 256 bits and using avx2 instructions on it!
- mitchellh 2mo ago
  > i've found that zig tends to extend my vectors to the native width of the platform and then operate on them there oh interesting. though i suspect that isn't zig and thats llvm.
  - wrl 2mo ago
    looks like it – compiled as debug (native linux x64 backend) gives me the vector type i've asked for. release modes extend to the "native" width. this is testing in isolation as well, could be that in the midst of other vector code it changes things. llvm definitely does a great job optimising tightly-written vector code to be even faster.
inigyou 2mo ago
Why does your website block Tor so I can't read the article?
- mitchellh 2mo ago
  No idea

dnautics 2mo 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)

fancyfredbot 2mo 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.
- dnautics 2mo ago
  "better" - for whom? will it cause problems if, for example you are writing scientific code?
wrl 2mo 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.
- dnautics 2mo ago
  > maybe functions that don't actually support actual vector execution just shouldn't work on vector arguments. i think that's reasonable.
BoingBoomTschak 2mo ago
https://sourceware.org/glibc/wiki/libmvec https://sourceware.org/glibc/wiki/libmvec ?