move to wasmer 3.1.1

[pdogr]

#3241
cargo audit still complains about mach

Crate:     mach
Version:   0.3.2
Warning:   unmaintained
Title:     mach is unmaintained
Date:      2020-07-14
ID:        RUSTSEC-2020-0168
URL:       https://rustsec.org/advisories/RUSTSEC-2020-0168
Dependency tree:
mach 0.3.2
├── wasmer-vm 3.1.1
│   ├── wasmer-compiler 3.1.1
│   │   ├── wasmer-compiler-singlepass 3.1.1
│   │   │   └── wasmer 3.1.1
│   │   │       ├── wasmer-wasi-types 3.1.1
│   │   │       │   └── wasmer-wasi 3.1.1
│   │   │       │       └── icu_codepointtrie_builder 0.3.5
│   │   │       │           └── icu_datagen 1.2.0
│   │   │       │               ├── tutorials-test 0.0.0
│   │   │       │               └── icu_testdata_scripts 0.0.0
│   │   │       ├── wasmer-wasi 3.1.1
│   │   │       └── icu_codepointtrie_builder 0.3.5
│   │   └── wasmer 3.1.1
│   └── wasmer 3.1.1
└── region 3.0.0
    ├── wasmer-vm 3.1.1
    └── wasmer-compiler 3.1.1

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• Cargo.lock is different
• components/collections/codepointtrie_builder/src/wasm.rs is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• Cargo.lock is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[sffc]

Nit: If you are not using lazy_static any more, please remove it from cargo.toml

[sffc]

Question: it seems like a regression that we need to parse the bytes to a module every time. Before we did it in the lazy_static, such that the first call was slow but every subsequent call was fast. It appears that Wasmer 3 requires the store to be mutable. I wonder why? It seems like we should still be able to create a Module just once and then an Instance for each call.

[sffc]

Actually does the store need to be the same for the Module and the Instance? Otherwise why would the API allow you to pass different arguments to both instead of just borrowing the store from the Module!

[pdogr]

The examples in https://github.com/wasmerio/wasmer/blob/v3.2.1/examples/hello_world.rs#L46-L71 also do the same.

[sffc]

Yes but those hello world examples don't need to re-use the module. We should be able to parse the module once and not be required to re-parse it on every function call, just as we were able to do in Wasmer 2.0.

CC @syrusakbary for potential advice on updating from wasmer 2 to wasmer 3.

[sffc]

^

[pdogr]

Some benches on Mac x86
Command run

cargo run --release --bin=icu4x-datagen --all-features -- --icuexport-root=../repodata/data/icuexport --syntax=postcard --out=/dev/null --format=blob --overwrite --keys=segmenter/word@1 --all-locales

This PR

INFO  [icu_datagen] Writing key: segmenter/word@1
INFO  [icu_provider_blob::export::blob_exporter] Serializing blob to output stream...

________________________________________________________
Executed in    2.84 secs    fish           external
   usr time    2.07 secs  260.00 micros    2.07 secs
   sys time    0.30 secs  995.00 micros    0.30 secs

HEAD @ 2f5c923

INFO  [icu_datagen] Writing key: segmenter/word@1
INFO  [icu_provider_blob::export::blob_exporter] Serializing blob to output stream...

________________________________________________________
Executed in    1.20 secs      fish           external
   usr time  968.95 millis  261.00 micros  968.68 millis
   sys time  440.98 millis  933.00 micros  440.05 millis

[sffc]

Make sure the bench is writing multiple keys that all use the WASM module. My thesis is that there's a perf regression when the module is being reused.

[robertbastian]

Well there's a perf regressions even for a single key...

[robertbastian]

Discussion: we want to update to wasmer 3, but there shouldn't be a performance hit.

[robertbastian]

.

[westy92]

The latest versions are now:

• wasmer 4.1.1
• wasmer-wasix 0.11.0

Perhaps the performance has been improved?

[robertbastian]

#4621