Upgrading from Wasmi 1.x? Please refer to the
Wasmi v1 to v2 migration guide
which lists all the changes that require action from users.
Wasmi 2.0.0 includes all changes of the 2.0.0-beta.0 up to 2.0.0-beta.10 releases.
Since those are far too many to repeat here, this entry only lists the highlights.
For the complete, PR-by-PR record please refer to the respective beta release entries:
- Wasmi v2.0.0-beta.10
- Wasmi v2.0.0-beta.9
- Wasmi v2.0.0-beta.8
- Wasmi v2.0.0-beta.7
- Wasmi v2.0.0-beta.6
- Wasmi v2.0.0-beta.5
- Wasmi v2.0.0-beta.4
- Wasmi v2.0.0-beta.3
- Wasmi v2.0.0-beta.2
- Wasmi v2.0.0-beta.1
- Wasmi v2.0.0-beta.0
Highlights
A completely new interpreter core
- Wasmi has an entirely new internal IR and executor. 🚀 #1655
- Benchmarks conclude that Wasmi v2.0 is geomean roughly 2.2x faster than Wasmi v1.0.
- Wasmi IR operators now store their results in accumulator registers, the same
interpreter architecture used by the fastest Wasm interpreters, Wasm3 and Stitch. - Wasmi's executor now uses fixed 64-bit cells. #1755
- Enabling the
simdcrate feature no longer affects memory consumption or
execution performance of non-simdWasm code.
- Enabling the
- Operator dispatch is tail-call based on targets that are known to support it and
falls back to the portable (loop-based) dispatch automatically via the new
default-enabledauto-dispatchcrate feature. #1968 - Re-designed
CodeMapto be lock-free and append-only significantly improving Wasm to Wasm call performance. - A new
InstanceEntitylayout plus caching greatly improved access to all instance related
data, namelyFunc,Global,Memory,Table,DataandElem.- PRs: #1940 #1996 #1997
- Despite Wasmi's module independent bytecode, instance access is now as efficient as in
Wasm3's or Stitch'es executors with their instance-related bytecodes. - The
count/globalsbenchmark improved by a whopping ~35%. wasmi::Tableelements shrank from 64-bit (or even 128-bit with thesimdcrate feature
enabled) to flat 32-bit references, shrinking Wasm tables by a factor of 2-4x.
Binary artifact size
- Added a new
validatecrate feature that controls whether Wasmi supports Wasm validation. #1902- Users who have full control over the Wasm inputs to Wasmi can reduce binary artifact
sizes by ~200-300kB by disabling it.
- Users who have full control over the Wasm inputs to Wasmi can reduce binary artifact
- Support for
memory64is now optional via thememory64crate feature. #1934 - Richer
Opdebug output moved behind a new, default-disableddebugcrate feature and
generic monomorphization in translation was replaced by explicit V-Tables.
Fuel metering
- Wasmi's fuel metering is now stable: it is tied to the input Wasm bytecode instead of
Wasmi's internal bytecode. #2013- While less precise, it stays relatively stable and is the same technique
that is also used in Wasmtime.
- While less precise, it stays relatively stable and is the same technique
- Fuel costs can now be customized via the new
Config::operator_costand
Config::fuel_costAPIs. #2025
Crate Features & configuration
- Added support for the Wasm deterministic profile via the new
deterministiccrate feature. #1947 - Added a
Configoption to disallow running thestartfunction of Wasm modules. #1985 - Added a new
libmcrate feature to enforcelibmusage. #1860 - Added a new
unstablecrate feature which enables Rust's unstablebecomekeyword to
enforce tail calls in Wasmi's operator dispatch on nightly Rust. #1825 - Added richer error information to Wasm module instantiation errors. #1962 #1963
- The Wasmi C-API now forwards most crate features exposed by
wasmi, including
portable-dispatch, and properly supportsno_std.