wasmtime / issue #7004 Support WASM's V128 as Rust u128 i... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #7004 Support WASM's V128 as Rust u128 i...

Wasmtime GitHub notifications bot (Sep 12 2023 at 14:34):

cylewitruk opened issue #7004:

Thanks for filing a feature request! Please fill out the TODOs below.

Feature

Wondering why V128 isn't supported in Func::wrap()? Both Walrus and Wasmer seem to allow V128's to be used in host functions mapped as u128's. I know this wasn't the "intended" use for V128's, but it would sure be nice for host functions :)

Benefit

Would allow passing of 128-bit numbers to/from host-functions without the need to split them into two parameters including lower and upper bits.

Implementation

Haven't looked into the Wasmtime internals, so no comment.

Alternatives

Passing two i64's low+high bits and bitwising them apart/together (fast, but boilerplate needed).

Using ExternRef's to pass u/i128's (slow)

Open to other suggestions...?

Wasmtime GitHub notifications bot (Sep 12 2023 at 14:40):

cylewitruk edited issue #7004:

Thanks for filing a feature request! Please fill out the TODOs below.

Feature

Wondering why V128 isn't supported in Func::wrap()? Both Walrus and Wasmer seem to allow V128's to be used in host functions mapped as u128's. I know this wasn't the "intended" use for V128's, but it would sure be nice for host functions, at least in Rust :)

Benefit

Would allow passing of 128-bit numbers to/from host-functions without the need to split them into two parameters including lower and upper bits.

Implementation

Haven't looked into the Wasmtime internals, so no comment.

Alternatives

Passing two i64's low+high bits and bitwising them apart/together (fast, but boilerplate needed).

Using ExternRef's to pass u/i128's (slow)

Open to other suggestions...?

Wasmtime GitHub notifications bot (Sep 12 2023 at 21:05):

alexcrichton commented on issue #7004:

I've been meaning to dust off this branch for some time now!

Wasmtime GitHub notifications bot (Sep 13 2023 at 10:25):

cylewitruk commented on issue #7004:

Well look at that! I searched issues and PR's before opening this and didn't find anything, but looks like it was hiding in a branch :) That would be really awesome, actually. We're currently evaluating Wasmtime as the runtime for stacks.co VM runtime for its Clarity language. As all numbers are currently treated as 128-bits, this would definitely save us some headaches! :D

Wasmtime GitHub notifications bot (Sep 13 2023 at 15:09):

alexcrichton commented on issue #7004:

One thing to keep in mind perhaps is that v128 is generally intended for vector/simd operations right now so it may not be totally suitable for 128-bit numbers since there's nothing like v128.add which performs a 128-bit addition. You may get more mileage out of pairs of u64 depending on your use case.

Additionally most engines may not be that optimal at this time passing around v128 as parameters and results. The v128 type is generally thought of "you use this in your hot inner loop and that's it". One example is that Cranelift/Wasmtime follow System-V which means that on RISC-V for example all arguments/results are passed through memory rather than in registers.

Not to say that this isn't a good use case, just figured it might be worth giving a heads up! I personally think it'd be reasonable to improve these sorts of issues if they arise. If you're interested in running on other engines though it might be worth testing there too

Wasmtime GitHub notifications bot (Sep 15 2023 at 22:06):

cylewitruk commented on issue #7004:

Very informed input, and good information for anyone else who might be wondering the same thing!

In our case we're aware of the limitations and that v128 was meant primarily for simd operations - we're currently passing low/high u64 pairs back-and-forth, but this does incur a slight overhead in host functions instead of simply being able to, for example, u128:.from_le_bytes(...).

Wasmtime GitHub notifications bot (Sep 15 2023 at 22:07):

cylewitruk edited a comment on issue #7004:

Very informed input, and good information for anyone else who might be wondering the same thing!

In our case we're aware of the limitations and that v128 was meant primarily for simd operations - we're currently passing low/high u64 pairs back-and-forth, but this does incur a slight overhead in host functions instead of simply being able to, for example, u128::from_le_bytes(...).

Wasmtime GitHub notifications bot (Sep 15 2023 at 22:42):

alexcrichton commented on issue #7004:

Ok sounds good! I forgot to close this earlier but this was solved by https://github.com/bytecodealliance/wasmtime/pull/7010.

If you notice any performance issues though in this area (or others) please let us know!

Wasmtime GitHub notifications bot (Sep 15 2023 at 22:42):

alexcrichton closed issue #7004:

Thanks for filing a feature request! Please fill out the TODOs below.

Feature

Wondering why V128 isn't supported in Func::wrap()? Both Walrus and Wasmer seem to allow V128's to be used in host functions mapped as u128's. I know this wasn't the "intended" use for V128's, but it would sure be nice for host functions, at least in Rust :)

Benefit

Would allow passing of 128-bit numbers to/from host-functions without the need to split them into two parameters including lower and upper bits.

Implementation

Haven't looked into the Wasmtime internals, so no comment.

Alternatives

Passing two i64's low+high bits and bitwising them apart/together (fast, but boilerplate needed).

Using ExternRef's to pass u/i128's (slow)

Open to other suggestions...?

Last updated: Dec 23 2024 at 12:05 UTC