Stream: git-wasmtime

Topic: wasmtime / issue #9826 [Wasmtime] Component model: Quenst...

view this post on Zulip Wasmtime GitHub notifications bot (Dec 15 2024 at 13:09):

kaivol opened issue #9826:

I noticed a significant performance penalty when returning list<f32> from WebAssembly components.
By overriding/specializing Lift::load_list for Vec<f32> (similar to the implementation for integers), I was able to achieve significantly better performance (I will make an issue or PR about this when I find the time).

While doing so I wondered whether it is necessary to canonicalize floating point numbers lifted/loaded from the WebAssembly runtime, as seen here: https://github.com/bytecodealliance/wasmtime/blob/128decddf236b21b60f4813f7ae01391428fef9a/crates/wasmtime/src/runtime/component/func/typed.rs#L932-L945
I understand that (in the Component Model) f32 and f64 logically only have a single NaN value.
Is it correct that for this reason we must ensure that we only pass the canonical NaN _to_ components?

Anyways I don't quite understand why this should be necessary for values passed _from_ components to the host, as Rust doesn't really make any promises about the bit patterns of NaN.
Also, shouldn't all floating point numbers coming from a component already be provided in canonical form, making another canonicalization redundant?

I would be delighted if someone could enlighten me about this.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 15 2024 at 19:52):

tschneidereit commented on issue #9826:

Good catch! This canonicalization used to be required by the specification, but that requirement has since been removed—precisely over the performance concerns you raise here. Seems like we never updated Wasmtime to match the spec change.

@alexcrichton, I assume removing the canonicalization here is fairly straight-forward?

view this post on Zulip Wasmtime GitHub notifications bot (Dec 15 2024 at 19:53):

tschneidereit added the performance label to Issue #9826.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 15 2024 at 19:53):

tschneidereit added the wasm-proposal:component-model label to Issue #9826.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 15 2024 at 20:28):

kaivol commented on issue #9826:

Thanks for the explanation!

view this post on Zulip Wasmtime GitHub notifications bot (Dec 16 2024 at 15:35):

alexcrichton commented on issue #9826:

Ah yes this is an artifact of the original implementation. @kaivol would you be interested in sending a PR for this? It in theory is as easy as "just remove canonicalize" I think

view this post on Zulip Wasmtime GitHub notifications bot (Dec 20 2024 at 17:16):

alexcrichton closed issue #9826:

I noticed a significant performance penalty when returning list<f32> from WebAssembly components.
By overriding/specializing Lift::load_list for Vec<f32> (similar to the implementation for integers), I was able to achieve significantly better performance (I will make an issue or PR about this when I find the time).

While doing so I wondered whether it is necessary to canonicalize floating point numbers lifted/loaded from the WebAssembly runtime, as seen here: https://github.com/bytecodealliance/wasmtime/blob/128decddf236b21b60f4813f7ae01391428fef9a/crates/wasmtime/src/runtime/component/func/typed.rs#L932-L945
I understand that (in the Component Model) f32 and f64 logically only have a single NaN value.
Is it correct that for this reason we must ensure that we only pass the canonical NaN _to_ components?

Anyways I don't quite understand why this should be necessary for values passed _from_ components to the host, as Rust doesn't really make any promises about the bit patterns of NaN.
Also, shouldn't all floating point numbers coming from a component already be provided in canonical form, making another canonicalization redundant?

I would be delighted if someone could enlighten me about this.

Last updated: Dec 23 2024 at 13:07 UTC