Annual survey finds SIMD in Rust mature, with std::simd still nightly-only
Victoria Shinder2 min readSergey "Shnatsel" Davidoff has published his second yearly survey of SIMD programming in Rust, and the headline is that the ecosystem has grown up: recent compiler features and libraries make Rust attractive for vectorised code even where memory safety is not the reason for choosing it. Davidoff now maintains one of the libraries he reviews, fearless_simd, and says so up front; to offset the conflict he sent the draft to the authors of std::simd, wide, pulp and macerator for comment while keeping editorial control.
Three language changes carry most of the progress. Since Rust 1.87 a function marked #[target_feature(enable = "avx2")] can call platform intrinsics without an unsafe block; loads and stores through raw pointers still need one, which libraries paper over with bounds-checked wrappers the optimiser then removes. Rust 1.98 stabilised "algebraic" float operations such as algebraic_add(), which let the compiler reorder float arithmetic and therefore auto-vectorise sums it previously had to leave scalar. And the standard library's portable std::simd remains the building block everything else wants - but it is still nightly-only and still takes occasional breaking changes.
The survey is blunt about limits. std::simd sits directly on LLVM, so it reaches any target LLVM supports, but where LLVM lacks a matching operation it silently emits scalar code; its sin() and reduce_sum() are singled out. The multiversion crate adds a call overhead of under a dozen instructions, which matters only on tiny functions. Crates whose development is mostly AI-driven are excluded from the recommendations outright, two of them for being demonstrably buggy.
What it means
The most useful section for anyone shipping vectorised code is the one on intrinsics, because it applies to C and C++ as much as to Rust. Davidoff describes an ARM load that the compiler treated as a black box, so loading a constant went through the stack twice; an LLVM "optimisation" that replaced a 512-bit shuffle with slower SSE4.2-era code, fixed in LLVM 23 after his report; and a list of still-open LLVM bugs. The lesson is that an intrinsic is not a guarantee of the instruction you asked for.
Two practical takeaways. If you distribute binaries, you need runtime dispatch - the survey cites Steam's hardware data at 23.9% of systems with AVX-512, so compiling for a fixed modern CPU is only safe on your own fleet. And if you rely on float trigonometry, check the generated assembly before trusting any library's vector version: by the author's own account, the best option he could find is a partial port that is still a little buggy.