Stream: git-wasmtime

Topic: wasmtime / PR #3319 Optimize `Func::call` and its C API

Wasmtime GitHub notifications bot (Sep 08 2021 at 21:27):

alexcrichton opened PR #3319 from optimize-call-take-two to main:

This commit is an alternative to #3298 which achieves effectively the
same goal of optimizing the Func::call API as well as its C API
sibling of wasmtime_func_call. The strategy taken here is different
than #3298 though where a new API isn't created, rather a small tweak to
an existing API is done. Specifically this commit handles the major
sources of slowness with Func::call with:

• Looking up the type of a function, to typecheck the arguments with and
  use to guide how the results should be loaded, no longer hits the
  rwlock in the Engine but instead each Func contains its own
  FuncType. This can be an unnecessary allocation for funcs not used
  with Func::call, so this is a downside of this implementation
  relative to #3298. A mitigating factor, though, is that instance
  exports are loaded lazily into the Store and in theory not too many
  funcs are active in the store as Func objects.

• Temporary storage is amortized with a long-lived Vec in the Store
  rather than allocating a new vector on each call. This is basically
  the same strategy as #3294 only applied to different types in
  different places. Specifically wasmtime::Store now retains a
  Vec<u128> for Func::call, and the C API retains a Vec<Val> for
  calling Func::call.

• Finally, an API breaking change is made to Func::call and its type
  signature (as well as Func::call_async). Instead of returning
  Box<[Val]> as it did before this function now takes a
  results: &mut [Val] parameter. This allows the caller to manage the
  allocation and we can amortize-remove it in wasmtime_func_call by
  using space after the parameters in the Vec<Val> we're passing in.
  This change is naturally a breaking change and we'll want to consider
  it carefully, but mitigating factors are that most embeddings are
  likely using TypedFunc::call instead and this signature taking a
  mutable slice better aligns with Func::new which receives a mutable
  slice for the results.

Overall this change, in the benchmark of "call a nop function from the C
API" is not quite as good as #3298. It's still a bit slower, on the
order of 15ns, because there's lots of capacity checks around vectors
and the type checks are slightly less optimized than before. Overall
though this is still significantly better than today because allocations
and the rwlock to acquire the type information are both avoided. I
personally feel that this change is the best to do because it has less
of an API impact than #3298.

<!--

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 08 2021 at 21:39):

alexcrichton updated PR #3319 from optimize-call-take-two to main.

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

alexcrichton updated PR #3319 from optimize-call-take-two to main.

Wasmtime GitHub notifications bot (Sep 21 2021 at 14:53):

alexcrichton requested peterhuene for a review on PR #3319.

Wasmtime GitHub notifications bot (Sep 21 2021 at 18:42):

peterhuene submitted PR review.

Wasmtime GitHub notifications bot (Sep 21 2021 at 18:42):

peterhuene submitted PR review.

Wasmtime GitHub notifications bot (Sep 21 2021 at 18:42):

peterhuene created PR review comment:

Can we not use the wasm_val_storage here, instead of a new allocation, if we exposed the store data via the associated StoreRef?

Wasmtime GitHub notifications bot (Sep 21 2021 at 18:58):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Sep 21 2021 at 18:58):

alexcrichton created PR review comment:

We could yeah. The reason I didn't do it here is that this is part of the wasm.h C API which uses different store data. We could update that too but I figured I didn't want to worry much about this and thought I could deal with it later if necessary. Given the later *_unchecked APIs I ended up adding I think that no one's gonna use these for the most performance hooks anyway.

Do you agree it's alright to leave this for some future refactoring, if necessary?

Wasmtime GitHub notifications bot (Sep 21 2021 at 18:59):

peterhuene submitted PR review.

Wasmtime GitHub notifications bot (Sep 21 2021 at 18:59):

peterhuene created PR review comment:

Definitely :+1:

Wasmtime GitHub notifications bot (Sep 21 2021 at 19:07):

alexcrichton merged PR #3319.

Last updated: Dec 23 2024 at 12:05 UTC