24,455 passing tests make the safety claim credible
SIMD lets one CPU instruction work on several values at once, but using it directly means juggling architecture-specific intrinsics and proving that the current processor supports them. Fearless SIMD puts those concerns behind safe Rust APIs. You can ask the compiler to vectorize a generic function, work with explicit vector types or enter a guarded kernel that exposes raw intrinsics.
The design is useful because it does not trap experienced users at one level. The optional #[simd] attribute handles the common case, dispatch! selects an implementation for the detected CPU and kernel! opens a checked route to NEON or x86 intrinsics. The core fearless_simd crate has zero dependencies; the procedural macro lives in a separately versioned companion crate.
What happened when we ran it
Our sandbox fetched 31 Cargo packages in 6 seconds and built commit 53685f7 in 17 seconds. The complete test command then ran for 134 seconds and reported 24,455 passed with 0 failed. For a low-level crate that promises the same behavior across scalar and vector backends, that result carries more weight than a quick example compiling once.
The checkout was 6.6 MB with 217 files and about 164,752 lines of source. We found 1 CI workflow, no Dockerfile and no conventional tests directory. The missing directory is not missing coverage: tests live in the fearless_simd_tests workspace crate, supported by development macros that generate cases for each SIMD level available on the machine.
Our result establishes that the workspace built and its available tests passed in a fresh 3-CPU, 12 GB Rust container. It does not measure speed, generated assembly or behavior on every supported instruction set. The test machine can only execute levels its hardware and container expose, so adopters still need architecture-specific CI and benchmarks for their shipping targets.
Rust 1.89 and two crates are the entry price
Fearless SIMD 1.0 requires Rust 1.89 or newer. Most users add the zero-dependency core crate and the optional macros crate, then mark SIMD-generic functions with #[simd]. Code can work without that annotation, but the README warns that achieving full performance then requires manual inlining care. That makes the macro the sensible default unless procedural macros are prohibited.
The API covers x86 and x86-64 from SSE2 through SSE4.2, AVX2 and selected AVX-512, plus Aarch64 NEON and 128-bit WebAssembly SIMD. A scalar fallback keeps code functional on machines without a supported SIMD level. Fixed-width vectors are available alongside types that use the native width selected by the backend.
std is enabled by default. A no_std project can select libm for floating-point functions, but one of those 2 features must be present. Runtime detection also changes outside std: the docs point library authors toward fallible detection and a baseline fallback. Embedded users should prototype that path before replacing working scalar code.
WebAssembly requires separate SIMD and scalar bundles
WebAssembly does not provide the runtime feature detection that Fearless SIMD uses on x86. The README tells browser developers to compile one bundle with simd128 and another without it, then select between them with a feature detector. Relaxed SIMD adds another opt-in build choice and can return hardware-dependent results where the crate already permits them.
That packaging cost is easy to miss in a native proof of concept. Cargo cannot set compiler flags per profile, so the documented approach uses a shell script to perform both builds. Teams with strict asset naming, caching or reproducible-build rules need to own that script and test both outputs. A single successful WASM compile is only half the deployment.
x86 dispatch trades binary size for wider CPU support
x86 support compiles versions of a generic function for several instruction sets and chooses one at runtime. This lets one binary use newer instructions without abandoning older CPUs. It also increases binary size. The README suggests codegen-units=1 or link-time optimization as partial remedies, both with longer build times, and offers configuration flags to disable selected automatic dispatch levels.
Performance still needs inspection. Issue 194 reports a 512-byte FFT path losing 20% throughput when dispatch! was called 3 times. Issue 163 discusses vector shifts that look similar in source but can fall back to scalar work on WebAssembly and SSE4.2. These reports do not make the API slow; they show where a convenient abstraction may hide a costly lowering or a badly placed dispatch boundary.
Version 1.0 is active while documentation catches up
Version 1.0.0 was released on September 21, 2026, and the repository was pushed again on September 26. GitHub listed 590 stars and 35 combined issues and pull requests. Current work includes byte compression, generic precise multiply-add implementations and swizzle optimization, all signs that maintainers are checking machine-level output rather than treating 1.0 as finished performance work.
The package README explains the three programming levels, target support, feature flags and deployment caveats well. Open issue 267 says operation tests and usage examples remain scattered, which matches the gap a new user will feel after the introductory examples. Fearless SIMD is ready to try now. The safe API and 24,455-test pass lower correctness risk, while the issue tracker tells you exactly why assembly inspection still belongs in the adoption plan.