Ulan Degenbaev (Mar 19 2024 at 11:02): Ulan Degenbaev (Mar 19 2024 at 11:02):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!
fitzgen (he/him) (Mar 19 2024 at 16:24):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!
Alex Crichton (Mar 19 2024 at 16:25):That's the intention, yes. Any non-deterministic behavior is considered a bug, and bugs do happen
Ulan Degenbaev (Mar 20 2024 at 09:31):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.
Alex Crichton (Mar 20 2024 at 14:23):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.
Chris Fallin (Mar 20 2024 at 14:43):@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
Jacob Lifshay (Mar 20 2024 at 16:57):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?
Alex Crichton (Mar 20 2024 at 17:00):I'm not at least personally aware of any denormal handling, no
Chris Fallin (Mar 20 2024 at 17:01):@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?
Jacob Lifshay (Mar 20 2024 at 17:09):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.
Dan Gohman (Mar 20 2024 at 17:39):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: Oct 23 2024 at 20:03 UTC