Hi folks. I have two questions about the implementation of Wasm SIMD in Wasmtime.
wasm_simd + cranelift_nan_canonicalization
guaranteed to be deterministic ?wasm_relaxed_simd + relaxed_simd_deterministic
guaranteed to be deterministic ?The documentation of these feature flags seems to imply that, but it would be great to get confirmation from people who know the implementation. Thanks!
cc @Alex Crichton, who implemented the relaxed SIMD stuff, and has a better handle on it than I do
@Ulan Degenbaev for anything confusing / ambiguous / missing in our docs, would love to have suggestions for what to say and where!
That's the intention, yes. Any non-deterministic behavior is considered a bug, and bugs do happen
Thanks you, @Alex Crichton and @fitzgen (he/him) !
@Ulan Degenbaev for anything confusing / ambiguous / missing in our docs, would love to have suggestions for what to say and where!
Explicitly stating that wasm_simd
is expected to be deterministic with NaN canonicalization would be helpful, but I am not sure if our use case is too specific since deterministic execution is critical for us.
Good point! I opened https://github.com/bytecodealliance/wasmtime/pull/8189 for covering that in the nan canonicalization docs.
Also FWIW @Ulan Degenbaev we don't have any fuzzing of this feature because we basically have nothing to fuzz it against, so for example the above issue is an example of where Wasmtime's behavior with respect to NaNs is changing over time. In Wasmtime 19 and prior f32.demote_f64
wasn't canonicalized but starting in Wasmtime 20 and later it'll be canonicalized now.
@Ulan Degenbaev as Alex notes re: lack of fuzzing -- this is a place where we'd welcome contributions from folks who have the specific need, I think. We all would like zero bugs here, but if your use-case has a special dependence on it today, perhaps it would make sense to build a fuzz target that (for example) looks for non-canonical NaN values at any observable point, and contribute that to the project. It might also be worth getting in touch with the person who filed the recent NaN-canonicalization-related bugs to see if there's a way to support their work
one other common cause of non-determinism cross-platform is does SIMD code use proper denormals or does it flush to zero (e.g. on ARMv7 NEON), does wasmtime have any special handling for that?
I'm not at least personally aware of any denormal handling, no
@Jacob Lifshay we don't support arm32 (ARMv7) so perhaps we've dodged that issue; are you aware of any such FP issues on aarch64?
Chris Fallin said:
Jacob Lifshay we don't support arm32 (ARMv7) so perhaps we've dodged that issue; are you aware of any such FP issues on aarch64?
no, I'm not aware of any issues; ARM wisely changed it to supporting denormals on AArch64, probably because not supporting denormals made it difficult to auto-vectorize code since the semantics could change.
For its part, the Wasm spec requires full subnormal support, including in SIMD, and the official testsuite has tests for this. When the CG voted it in the SIMD proposal, the feeling was that the intersection of people using Wasm, using SIMD, using f32, and using armv7 together is small enough that it's ok to just require armv7 Wasm engines to lower f32x4 to scalar operations.
Last updated: Dec 23 2024 at 12:05 UTC