alexcrichton opened PR #8629 from alexcrichton:remove-native-abi
to bytecodealliance:main
:
This commit proposes removing the "native abi" calling convention used in Wasmtime. For background this ABI dates back to the origins of Wasmtime. Originally Wasmtime only had
Func::call
and eventually I addedTypedFunc
withTypedFunc::call
andFunc::wrap
for a faster path. At the time given the state of trampolines it was easiest to call WebAssembly code directly without any trampolines using the native ABI that wasm used at the time. This is the original source of the native ABI and it's persisted over time under the assumption that it's faster than the array ABI due to keeping arguments in registers rather than spilling them to the stack.Over time, however, this design decision of using the native ABI has not aged well. Trampolines have changed quite a lot in the meantime and it's no longer possible for the host to call wasm without a trampoline, for example. Compilations nowadays maintain both native and array trampolines for wasm functions in addition to host functions. There's a large split between
Func::new
andFunc::wrap
. Overall, there's quite a lot of weight that we're pulling for the design decision of using the native ABI.Functionally this hasn't ever really been the end of the world. Trampolines aren't a known issue in terms of performance or code size. There's no known faster way to invoke WebAssembly from the host (or vice-versa). One major downside of this design, however, is that
Func::new
requires Cranelift as a backend to exist. This is due to the fact that it needs to synthesize various entries in the matrix of ABIs we have that aren't available at any other time. While this is itself not the worst of issues it means that the C API cannot be built without a compiler because the C API does not have access toFunc::wrap
.Overall I'd like to reevaluate given where Wasmtime is today whether it makes sense to keep the native ABI trampolines. Sure they're supposed to be fast, but are they really that much faster than the array-call ABI as an alternative? This commit is intended to measure this.
This commit removes the native ABI calling convention entirely. For example
VMFuncRef
is now one pointer smaller. All ofTypedFunc
now uses*mut ValRaw
for loads/stores rather than dealing with ABI business. The benchmarks with this PR are:
sync/no-hook/core - host-to-wasm - typed - nop
- 5% fastersync/no-hook/core - host-to-wasm - typed - nop-params-and-results
- 10% slowersync/no-hook/core - wasm-to-host - typed - nop
- no changesync/no-hook/core - wasm-to-host - typed - nop-params-and-results
- 7% fasterThese numbers are a bit surprising as I would have suspected no change in both "nop" benchmarks as well as both being slower in the params-and-results benchmarks. Regardless it is apparent that this is not a major change in terms of performance given Wasmtime's current state. In general my hunch is that there are more expensive sources of overhead than reads/writes from the stack when dealing with wasm values (e.g. trap handling, store management, etc).
Overall this commit feels like a large simplification of what we currently do in
TypedFunc
:
- The number of ABIs that Wasmtime deals with is reduced by one. ABIs are pretty much always tricky and having fewer moving parts should help improve the understandability of the system.
- All of the
WasmTy
trait methods andTypedFunc
infrastructure is simplified. Traits now work with simpleload
/store
methods rather than various other flavors of conversion.- The multi-return-value handling of the native ABI is all gone now which gave rise to significant complexity within Wasmtime's Cranelift translation layer in addition to the
TypedFunc
backing traits.- This aligns components and core wasm where components always use the array ABI and now core wasm additionally will always use the array ABI when communicating with the host.
I'll note that this still leaves a major ABI "complexity" with respect to native functions do not have a wasm ABI function pointer until they're "attached" to a
Store
with aModule
. That's required to avoid needing Cranelift for creating host functions and that property is still true today. This is a bit simpler to understand though now thatFunc::new
andFunc::wrap
are treated uniformly rather than one being special-cased.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
alexcrichton requested wasmtime-core-reviewers for a review on PR #8629.
alexcrichton requested elliottt for a review on PR #8629.
alexcrichton requested fitzgen for a review on PR #8629.
github-actions[bot] commented on PR #8629:
Subscribe to Label Action
cc @fitzgen
<details>
This issue or pull request has been labeled: "wasmtime:api", "wasmtime:ref-types"Thus the following users have been cc'd because of the following labels:
- fitzgen: wasmtime:ref-types
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
fitzgen submitted PR review:
Ship it!
alexcrichton updated PR #8629.
alexcrichton has enabled auto merge for PR #8629.
alexcrichton updated PR #8629.
alexcrichton has enabled auto merge for PR #8629.
alexcrichton merged PR #8629.
Last updated: Dec 23 2024 at 12:05 UTC