Stream: git-wasmtime

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


view this post on Zulip 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:

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.

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

view this post on Zulip Wasmtime GitHub notifications bot (Sep 03 2021 at 19:04):

alexcrichton updated PR #3298 from arguments to main.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 03 2021 at 20:24):

alexcrichton updated PR #3298 from arguments to main.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 13 2021 at 18:05):

alexcrichton closed without merge PR #3298.


Last updated: Dec 23 2024 at 12:05 UTC