Open alecmocatta opened 1 month ago
Does anyone know a way to implement a fallback so that we can use intrinsics and fall back to the generic version if that fails? Otherwise we might add a feature to force the generic version on wasm for such browsers and the user will either have to supply a browser check to select the best version or live with the suboptimal performance on browsers supporting SIMD.
@llogiq A Wasm binary that includes unsupported intrinsics can fail to parse, even if it won't use them. This comment is accurate unfortunately https://github.com/BurntSushi/memchr/issues/144#issuecomment-1887216278:
The current way of doing feature detection with WASM on browsers is to try to load a small WASM with the specific feature and see whether it fails. See for example this library from Google.
The route memchr
took https://github.com/BurntSushi/memchr/pull/149 is to only use intrinsics when #[cfg(target_feature = "simd128")]
. This way you can force the intrinsic or generic version at compile-time with or without RUSTFLAGS=-Ctarget-feature=+simd128
. Alternately:
[target.wasm32-unknown-unknown]
rustflags = ["-Ctarget-feature=+simd128"]
Apps can then build multiple binaries, and use feature detection to serve the optimal one. For the foreseeable future this is the only portable option as far as I know.
I believe I'm seeing the same as this issue with this crate:
Here's wasm2wat showing the functions at issue: