Here's to hoping Zig gets explicit SIMD intrinsics in 1.0. It is one of the few things holding me back. That and the pedantic compiler errors around unused variables.
I'm pretty new to Zig, but after taking another look recently I was pleasantly surprised by the progress on SIMD operations via builtin Vector types [1],[2]. For an application of "I want to speed up my math-intensive code with SIMD while supporting x86-64, aarch64, and non-SIMD fallbacks" it might be suitable for you now, and Zig certainly exposes more readable SIMD syntax than with C intrinsics imho [3]. But if you have a particular CPU instruction in mind, you're still a little bit at the mercy of the compiler as operations on Vector types aren't explicitly tied to particular CPU instructions.
It's planned to have feature parity with all the intrinsics that are available in the wild, for any CPU architecture. The difference with C is that we want to make the intrinsics part of the language; not a compiler extension. So, while you could do compile-time CPU feature detection to check if an intrinsic will lower to machine code and choose a different implementation, you could also just express the code with the intrinsics and let the compiler decide how to lower it. It will use shims for any machine that does not have native instructions.
Anyway, please file feature requests for missing SIMD intrinsics!
Maybe have a look at Java’s new Vector API. It may be strange to get inspiration from a managed language, but I do think that it is a very sane API with safe fallbacks on non-supported CPUs (though it is possible only due to the JIT that way)
And where the CPU doesn't support some SIMD intrinsics—SWAR for the win! I've been digging into Zig's Vectors the past week and really like the decisions. Thanks!
Here's to hoping Zig gets explicit SIMD intrinsics in 1.0. It is one of the few things holding me back. That and the pedantic compiler errors around unused variables.