wasmtime / issue #6932 compatibility of a serialized modu... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #6932 compatibility of a serialized modu...

Wasmtime GitHub notifications bot (Aug 30 2023 at 12:39):

gggrafff opened issue #6932:

Hello!
I use wasmtime-go. I want to create a module and serialize Module.Serialize() on a first machine, and deserialize Module.NewModuleDeserialize() - on another one. But the machines have different processors (Intel Xeon Silver 4114 vs Intel Xeon E-2276G) and I get the error compilation setting "has_avx512dq" is enabled, but not available on the host.
Which engine config option should I turn off to ensure compatibility? And is it possible?
Thanks!

Wasmtime GitHub notifications bot (Aug 30 2023 at 12:58):

gggrafff edited issue #6932:

Hello!
I use wasmtime-go. I want to create a module and serialize Module.Serialize() on a first machine, and deserialize Module.NewModuleDeserialize() - on another one. But the machines have different processors (Intel Xeon Silver 4114 vs Intel Xeon E-2276G) and I get the error compilation setting "has_avx512dq" is enabled, but not available on the host.
Which engine config option should I turn to ensure compatibility? And is it possible?
Thanks!

Wasmtime GitHub notifications bot (Aug 30 2023 at 13:00):

bjorn3 commented on issue #6932:

The Rust api has the target method which will cause it to use the baseline features of the specified target without inferring supported features from the host. It seems like the Go api is missing it.

Wasmtime GitHub notifications bot (Aug 30 2023 at 13:18):

gggrafff commented on issue #6932:

@bjorn3 thank you
Do you mean this option https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.target ?
Where can I read a more detailed description, in what format do I need to pass values for this option and how do I understand what value I need?

Wasmtime GitHub notifications bot (Aug 30 2023 at 13:18):

gggrafff edited a comment on issue #6932:

@bjorn3 thank you
Do you mean this https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.target ?
Where can I read a more detailed description, in what format do I need to pass values for this option and how do I understand what value I need?

Wasmtime GitHub notifications bot (Aug 30 2023 at 13:23):

gggrafff edited a comment on issue #6932:

@bjorn3 thank you
Do you mean this https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.target ?
Where can I read a more detailed description, in what format do I need to pass values for this option and how do I understand what value I need?

UPD: I found
https://docs.wasmtime.dev/wasm-rust.html#rust

Wasmtime GitHub notifications bot (Aug 30 2023 at 13:27):

gggrafff edited a comment on issue #6932:

@bjorn3 thank you
Do you mean this https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.target ?
Where can I read a more detailed description, in what format do I need to pass values for this option and how do I understand what value I need?

UPD: I found
https://docs.wasmtime.dev/wasm-rust.html#rust

UPDUPD: or not, it seems like another targets, not for wasmtime

Wasmtime GitHub notifications bot (Aug 30 2023 at 13:28):

gggrafff edited a comment on issue #6932:

@bjorn3 thank you
Do you mean this https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.target ?
Where can I read a more detailed description, in what format do I need to pass values for this option and how do I understand what value I need?

UPD: I found
https://docs.wasmtime.dev/wasm-rust.html#rust

UPDUPD: or not, it seems like other targets, not for wasmtime

Wasmtime GitHub notifications bot (Aug 30 2023 at 13:57):

gggrafff commented on issue #6932:

I used rustc to find out the host triple on both machines, and it's the same: `host triple: x86_64-unknown-linux-gnu'. Does this mean that serialized modules should be compatible?

I used the wasmtime cli to run wasmtime compile --target=x86_64-unknown-linux-gnu on both machines, and compare the result. Even with explicit targeting, the compilation result is different on the two machines.

First:
root@docker5:/app# md5sum main.wasm
1a84290c20ad87e3bf1deacd6fb20050  main.wasm
root@docker5:/app# wasmtime compile main.wasm
root@docker5:/app# md5sum main.wasmc
01070422fdc1d3943d40f711fa1a2c75  main.wasmc
root@docker5:/app# wasmtime compile --target=x86_64-unknown-linux-gnu main.wasm
root@docker5:/app# md5sum main.wasmc
01070422fdc1d3943d40f711fa1a2c75  main.wasmc
Second:
root@docker1:/app# md5sum main.wasm
1a84290c20ad87e3bf1deacd6fb20050  main.wasm
root@docker1:/app# wasmtime compile main.wasm
root@docker1:/app# md5sum main.wasmc
dfe56884f884bffad84f79122d6765a6  main.wasmc
root@docker1:/app# wasmtime compile --target=x86_64-unknown-linux-gnu main.wasm
root@docker1:/app# md5sum main.wasmc
dfe56884f884bffad84f79122d6765a6  main.wasmc
That is, the target option does not force the compiler to use only baseline features? Or does it need some special target value?

Wasmtime GitHub notifications bot (Aug 30 2023 at 14:11):

alexcrichton commented on issue #6932:

@bjorn3 is right in that --target or calling Config::target should reset the baseline features, but @gggrafff in your example you're calling md5sum main.wasmc when the output of Wasmtime is main.cwasm (note the different extension), is that a typo in the copy/paste? If you use cwasm does the output artifact change?

Wasmtime GitHub notifications bot (Aug 30 2023 at 14:26):

gggrafff commented on issue #6932:

@alexcrichton
Thank you, you are the best
It was my mistake, I mixed up the file extensions
I repeated the experiment and really got the same files as expected

I'll try to pass the target parameter from the Go API.
Or I'll use the cli. Can I call NewModule/NewModuleDeserialize for a cwasm file obtained using the 'wasmtime compile` cli?

Wasmtime GitHub notifications bot (Aug 30 2023 at 14:28):

alexcrichton commented on issue #6932:

To confirm, when you say you "really got the same files as expected", does that means that --target changed the output artifact?

Currently the --target option isn't exposed from the C API which is what Go is built on, but I can send a PR for that. In the meantime, yes, wasmtime compile on the CLI should produce something usable to load in Go. Do be aware though that the underlying versions of Wasmtime must match, so it'd be two pieces to keep in sync.

Wasmtime GitHub notifications bot (Aug 30 2023 at 18:33):

gggrafff commented on issue #6932:

Thanks,
Yes, --target changed the output artifact

Wasmtime GitHub notifications bot (Aug 30 2023 at 19:01):

alexcrichton commented on issue #6932:

Ok great! In that case I think this is handled now so I'm going to close this. #6934 added the relevant bits to the C API which the 13.0.0 release of wasmtime-go will be able to expose at the Go layer

Wasmtime GitHub notifications bot (Aug 30 2023 at 20:04):

alexcrichton closed issue #6932:

Hello!
I use wasmtime-go. I want to create a module and serialize Module.Serialize() on a first machine, and deserialize Module.NewModuleDeserialize() - on another one. But the machines have different processors (Intel Xeon Silver 4114 vs Intel Xeon E-2276G) and I get the error compilation setting "has_avx512dq" is enabled, but not available on the host.
Which engine config option should I turn to ensure compatibility? And is it possible?
Thanks!

Last updated: Dec 23 2024 at 12:05 UTC