Third one from the ruvector-diskann source read (main c55e9e8), this one aimed at wasm portability.
Today: the simd feature routes distance through simsimd, which targets NEON/AVX2/AVX-512 — it does not cover wasm32. So every wasm build of the distance path takes the scalar fallbacks (scalar_l2_squared / scalar_inner_product, distance.rs:84-166). The 4-accumulator ILP helps LLVM a bit, but explicit 128-bit SIMD is left on the table exactly on the target where portability matters most.
Proposal: core::arch::wasm32 v128 kernels for l2_squared, inner_product, and PQ distance-table construction, gated under #[cfg(all(target_arch = "wasm32", target_feature = "simd128"))] with the same dispatch shape the simd feature already uses. Zero effect on native builds; no new dependency.
This also slots into the ruvector-rabitq VectorKernel registry, which is already designed for pluggable kernel ids — a "wasm-simd128" kernel alongside the anticipated "metal" one.
The lattice embedding provider in this tree already ships a wasm build, so we'd contribute these kernels with scalar-vs-simd128 A/B measurements (Node and browser) in the PR body — no speedup claims up front, measured or not claimed.
Together with #673 and #674 this is groundwork for a wasm DiskANN package (filing that as the capstone issue).
Third one from the
ruvector-diskannsource read (main c55e9e8), this one aimed at wasm portability.Today: the
simdfeature routes distance through simsimd, which targets NEON/AVX2/AVX-512 — it does not coverwasm32. So every wasm build of the distance path takes the scalar fallbacks (scalar_l2_squared/scalar_inner_product,distance.rs:84-166). The 4-accumulator ILP helps LLVM a bit, but explicit 128-bit SIMD is left on the table exactly on the target where portability matters most.Proposal:
core::arch::wasm32v128 kernels forl2_squared,inner_product, and PQ distance-table construction, gated under#[cfg(all(target_arch = "wasm32", target_feature = "simd128"))]with the same dispatch shape thesimdfeature already uses. Zero effect on native builds; no new dependency.This also slots into the
ruvector-rabitqVectorKernelregistry, which is already designed for pluggable kernel ids — a"wasm-simd128"kernel alongside the anticipated"metal"one.The lattice embedding provider in this tree already ships a wasm build, so we'd contribute these kernels with scalar-vs-simd128 A/B measurements (Node and browser) in the PR body — no speedup claims up front, measured or not claimed.
Together with #673 and #674 this is groundwork for a wasm DiskANN package (filing that as the capstone issue).