-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove the native ABI calling convention from Wasmtime #8629
Merged
alexcrichton
merged 2 commits into
bytecodealliance:main
from
alexcrichton:remove-native-abi
May 17, 2024
Merged
Remove the native ABI calling convention from Wasmtime #8629
alexcrichton
merged 2 commits into
bytecodealliance:main
from
alexcrichton:remove-native-abi
May 17, 2024
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
alexcrichton
requested review from
elliottt and
fitzgen
and removed request for
a team and
elliottt
May 15, 2024 21:15
github-actions
bot
added
wasmtime:api
Related to the API of the `wasmtime` crate itself
wasmtime:ref-types
Issues related to reference types and GC in Wasmtime
labels
May 15, 2024
Subscribe to Label Actioncc @fitzgen
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:
To subscribe or unsubscribe from this label, edit the |
fitzgen
approved these changes
May 17, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ship it!
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 added `TypedFunc` with `TypedFunc::call` and `Func::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` and `Func::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 to `Func::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 of `TypedFunc` 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% faster * `sync/no-hook/core - host-to-wasm - typed - nop-params-and-results` - 10% slower * `sync/no-hook/core - wasm-to-host - typed - nop` - no change * `sync/no-hook/core - wasm-to-host - typed - nop-params-and-results` - 7% faster These 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 and `TypedFunc` infrastructure is simplified. Traits now work with simple `load`/`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 a `Module`. 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 that `Func::new` and `Func::wrap` are treated uniformly rather than one being special-cased.
alexcrichton
force-pushed
the
remove-native-abi
branch
from
May 17, 2024 03:40
f5a1253
to
ce58e1c
Compare
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
May 17, 2024
prtest:full
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
May 17, 2024
This commit enables the `Func::new` constructor and related other functions when `cranelift` and `winch` features are both disabled, meaning this is now available in compiler-less builds. This builds on the support of bytecodealliance#8629.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
May 20, 2024
…nce#8629) * Remove the native ABI calling convention from Wasmtime 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 added `TypedFunc` with `TypedFunc::call` and `Func::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` and `Func::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 to `Func::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 of `TypedFunc` 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% faster * `sync/no-hook/core - host-to-wasm - typed - nop-params-and-results` - 10% slower * `sync/no-hook/core - wasm-to-host - typed - nop` - no change * `sync/no-hook/core - wasm-to-host - typed - nop-params-and-results` - 7% faster These 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 and `TypedFunc` infrastructure is simplified. Traits now work with simple `load`/`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 a `Module`. 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 that `Func::new` and `Func::wrap` are treated uniformly rather than one being special-cased. * Fix miri unsafety prtest:full
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
May 20, 2024
This commit enables the `Func::new` constructor and related other functions when `cranelift` and `winch` features are both disabled, meaning this is now available in compiler-less builds. This builds on the support of bytecodealliance#8629.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
wasmtime:api
Related to the API of the `wasmtime` crate itself
wasmtime:ref-types
Issues related to reference types and GC in Wasmtime
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
:WasmTy
trait methods andTypedFunc
infrastructure is simplified. Traits now work with simpleload
/store
methods rather than various other flavors of conversion.TypedFunc
backing traits.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.