hydroplane

Float-agnostic, ISPC-style SPMD/SIMD infrastructure for Rust. Write one kernel, get nearly optimal code everywhere: the kernel is written once against a lane-agnostic context, and both the ISA width and the ILP unroll factor are raised for you, at compile time when the target is pinned, by runtime detection otherwise. Stable Rust, no_std-compatible, no SIMD-crate dependency. Hydroplane also works with GPU backends via rust-gpu and SPIR-V, enabling the same kernel code to run on graphics hardware. GPU functionality is still evolving and the hyper optimized performance promises cannot be made the same there as on the CPU backends.

use hydroplane::{Gang, kernel};

#[kernel]
fn dot<'a>(ctx: Gang, a: &'a [f32], b: &'a [f32]) -> f32 {
    ctx.zip_fold(a, b, 0.0, 0.0, ctx.splat(0.0), |acc, x, y| acc + x * y)
        .reduce_sum()
}

let s = dot(&a, &b); // dispatched: AVX-512 / AVX2 / SSE4 / NEON / SVE / ... picked per host

#[kernel] monomorphizes the body per backend and generates a dispatching wrapper (plus an _on companion for composing kernels on an already-selected backend). Besides the leading ctx: Gang argument, a kernel is no different from any other Rust function: ordinary parameters, borrows, generics, and return type, called like a plain fn — dot(&a, &b) above. Kernels never name an ISA. Elements are generic too: one body serves f32, f64, f16, bf16 (half types widen-compute-narrow unless the target has native lanes). Integers are supported as well: u32 and i32 are first-class kernel scalars and also run as companion lanes alongside float kernels for argmin-style index tracking and float bit manipulation via to_bits/from_bits.

What "raising" means

• ISA raising. At run time the dispatcher picks the widest implemented backend the CPU supports; the SIMD ops are #[target_feature] bodies, so a generic x86 binary still uses AVX-512 on a host that has it. With --cfg hp_static_dispatch + a pinned target-cpu the ladder folds into one unconditional call at compile time.
• ILP raising. Reductions and maps run K independent register chains to saturate the core's FP pipes. K is measured once per process by a startup sweep and baked into the monomorphized kernel as a compile-time constant (Unroll<S, K>); on pinned builds build.rs resolves it at build time instead. This is routinely worth more than lane width on latency-bound loops — see the case study.

Backends

Three layers: raw Backend ops → the ergonomic Gang/Varying surface (operator-overloaded registers, masks, chunking/tail combinators, SoA storage) → MatrixBackend/dense (register-blocked GEMM tiles; runtime-shaped BLAS-lite).

Benchmarks

Paired implementations of each workload — hydroplane #[kernel] (hp), hand-rolled wide SIMD with manual ILP (wide), and a plain scalar loop (scalar) — live in hydroplane-example. Apple M5 Pro, rustc 1.95, RUSTFLAGS="-C target-cpu=native", criterion --quick, n = 4096 f32 elements; correctness is asserted against the scalar oracle before timing.

RUSTFLAGS="-C target-cpu=native" cargo bench -p hydroplane-example --bench workloads

For the full progression, scalar → portable wide → wide restructured for ILP → hydroplane (with raw NEON intrinsics as the ceiling reference) on one problem, with the mechanics of why each step pays (read CASE_STUDY.md ):

Cargo features

f16/bf16 support (via half) is always on and re-exported from the crate root.

Build-time configuration

All opt-in via RUSTFLAGS="--cfg <name>":

Workspace

• hydroplane-macros — the #[kernel] proc macro.
• hydroplane-auto — optional build-time MIR analysis that sizes unroll/inlining decisions per kernel.
• hydroplane-example — the paired benchmark workloads above.

License: Apache-2.0.