Sourced from wasmi's releases.
v0.29.0 - 2023-03-20
Added
- Added support for
extended-constWasm proposal. (paritytech/wasmi#707)- Added fuel consumption modes. (paritytech/wasmi#706)
- This allows eager and lazy fuel consumption modes to be used which mainly affects bulk operations such as
table.copyandmemory.grow. Eager fuel consumption always consumes fuel before a bulk operation for the total amount independent of success or failure of the operation whereras lazy fuel consumption only consumes fuel for successful executions.Changed
- Normalize fuel costs of all instructions. (paritytech/wasmi#705)
- With this change most instructions cost roughly 1 fuel upon execution. This is more similar to how Wasmtime deals with fuel metered instruction costs. Before this change
wasmitried to have fuel costs that more closely mirror the computation intensity of the respective instruction according to benchmarks.
Sourced from wasmi's changelog.
[
0.29.0] - 2023-03-20Added
- Added support for
extended-constWasm proposal. (paritytech/wasmi#707)- Added fuel consumption modes. (paritytech/wasmi#706)
- This allows eager and lazy fuel consumption modes to be used which mainly affects bulk operations such as
table.copyandmemory.grow. Eager fuel consumption always consumes fuel before a bulk operation for the total amount independent of success or failure of the operation whereras lazy fuel consumption only consumes fuel for successful executions.Changed
- Normalize fuel costs of all instructions. (paritytech/wasmi#705)
- With this change most instructions cost roughly 1 fuel upon execution. This is more similar to how Wasmtime deals with fuel metered instruction costs. Before this change
wasmitried to have fuel costs that more closely mirror the computation intensity of the respective instruction according to benchmarks.[
0.28.0] - 2023-03-01Added
- Added support for the
tail-callWasm proposal. (paritytech/wasmi#683)- Added support for
Linkerdefined host functions. (paritytech/wasmi#692)
- Apparently this PR introduced some performance wins for the Wasm target according to our tests. This information shall be taken with a grain of salt since we are not sure why those performance improvement occured since the PR's functionality is orthogonal to Wasm engine performance.
- Required precursor refactoring PR: paritytech/wasmi#681
Changed
- The
wasmi_wasicrate now more closely mirrors thewasmtime_wasicrate API. (paritytech/wasmi#700)Internal
- Refactor the
wasmiWasm engine to handle Wasm calls and returns in its core. [(#694)]
- This improved performance of Wasm function calls significantly at the cost of host function call performance.
- Also this seemed to have impacts Wasm target performance quite positively, too.
- The
Storenow handles Wasm functions and host functions separately. (paritytech/wasmi#686)
- This allows to store Wasm functions into the
StoreInnertype which was an important step towards the major refactoring in [(#694)]- It was expected that host function call performance would degrade by this PR but our tests actually showed that the opposite was true and Wasm target performance was improved overall.
- Introduce
ValueStackPtrabstraction for thewasmiengine core. (paritytech/wasmi#688)
- This change significantly improved performance especially on the Wasm target according to our tests.
- Optimize
memory.{load,store}when reading or writing single bytes. (paritytech/wasmi#689)
... (truncated)
23d8d8c
Prepare wasmi release of version 0.29.0 (#708)eb8d73f
Add extended-const Wasm proposal support (#707)6dbbada
Add fuel consumption modes (#706)cf7736f
Normalize fuel costs to roughly 1 fuel per executed instruction (#705)223f815
Update and refactor the wasmi_wasi crate (#700)