Stream: git-wasmtime

Topic: wasmtime / PR #3298 Add a new API to make `Func::call` fa...

Wasmtime GitHub notifications bot (Sep 03 2021 at 18:07):

alexcrichton opened PR #3298 from arguments to main:

The fastest way to call a WebAssembly function with Wasmtime is to use
the TypedFunc API and methods. This is only available to Rust code,
however, due to the usage of generics. The C API as a result is left to
only be able to use Func::call, which is quite slow today. While
Func::call has a lot of reasons that it's slow, some major
contributors are:

• Space must be allocated for the arguments/return values to call the
  trampoline with. This u128 storage is allocated on all
  Func::call-based calls today.

• The function's type is loaded to typecheck the arguments, and this
  requires taking an rwlock in the Engine as well as cloning out the
  FuncType itself.

• For the C API the slice of inputs needs to be translated to a slice of
  Val, and the results are translated from a vector of Val back to a
  vector of wasmtime_val_t.

These two operations are particularly costly and the goal of this commit
is to solve these two issues. The solution implemented here is a new
structure, called FuncStorage, which can be created within an Engine
on a per-function-type basis. This storage is then used with a new API,
Func::call_with_storage, which removes the first two slowdowns mentioned
above. Each FuncStorage stores a copy of the FuncType it's intended
to be used with. Additionally it stores an appropriately-sized
Vec<u128> for storage of trampoline-encoded arguments.

The final bullet above is solved with tweaks to the
Func::call_with_storage API relative to Func::call where the
parameters/results are both iterators instead of slices.

This new API is intended to be a "power user" API for the Rust crate,
but is expected to be more commonly used with the C API since it's such
a large performance improvement to calling wasm functions.

Overall I'm not overly happy with this API. It solves a lot of the slow
wasmtime_func_call problem, but the APIs added here are pretty
unfortunate I think. Ideally we could solve this issue with no
additional API surface area. For example the first bullet could be
solved with a solution along the lines of #3294 where vectors are stored
in a Store and reused per-call. The third bullet could probably be
fixed with the same style and also changing Func::call to taking a
&mut [Val] as an argument instead of returning a boxed slice. The
second bullet though is probably one of the harder ones to fix. Each
Func could store it's fully-fleshed-out FuncType, but that's a
relatively large impact and would also likely require changing
FuncType to internally use Arc<[WasmType]> or similar. In any case
I'm hoping that this can help spur on some creativity for someone to
find a better solution to this issue.

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Sep 03 2021 at 19:04):

alexcrichton updated PR #3298 from arguments to main.

Wasmtime GitHub notifications bot (Sep 03 2021 at 20:24):

alexcrichton updated PR #3298 from arguments to main.

Wasmtime GitHub notifications bot (Sep 13 2021 at 18:05):

alexcrichton closed without merge PR #3298.

Last updated: Nov 22 2024 at 16:03 UTC