Stream: git-wasmtime

Topic: wasmtime / PR #3736 Add a simple "server" benchmark.

Wasmtime GitHub notifications bot (Jan 27 2022 at 22:58):

cfallin opened PR #3736 from server-benchmark to main:

This benchmark repeatedly instantiates and invokes the start function on
a module, from multiple threads in parallel. It is meant to be a simple
test harness for optimizing e.g. instance allocators and other core
runtime functionality.

Split off from #3697.

<!--

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 (Jan 27 2022 at 22:58):

cfallin requested alexcrichton for a review on PR #3736.

Wasmtime GitHub notifications bot (Jan 28 2022 at 14:33):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jan 28 2022 at 14:33):

alexcrichton created PR review comment:

Each iteration can take a variable amount of time since it goes to a different module, so would it be better to ensure that iters is rounded up/down to a multiple of the number of modules to ensure we don't see effects where "the really slow module" is run one less time than the others?

Wasmtime GitHub notifications bot (Jan 28 2022 at 14:33):

alexcrichton created PR review comment:

Is this generally intended to limit the number of instances to ensure instantiation always succeeds? For example without this do too many instances get spawned?

Wasmtime GitHub notifications bot (Jan 28 2022 at 14:33):

alexcrichton created PR review comment:

For benchmarking I think it might be better to use get_typed_func here which is more expected in server-like situations.

Wasmtime GitHub notifications bot (Jan 28 2022 at 14:33):

alexcrichton created PR review comment:

Perhaps instead of a "make engine" function could this be a "make config" function? Dealing with boolean parameters typically requires commenting at each use-site what the parameter means and it's not all that hard to create an Engine from a config so dealing with just configs here might be easier?

Wasmtime GitHub notifications bot (Jan 28 2022 at 14:33):

alexcrichton created PR review comment:

I actually naively thought that block_on only waited for the future specified, but to confirm this does indeed wait for all the spawned tasks to return?

Wasmtime GitHub notifications bot (Jan 28 2022 at 14:33):

alexcrichton created PR review comment:

Could this use if cfg!(...) instead of #[cfg]?

Wasmtime GitHub notifications bot (Jan 28 2022 at 14:33):

alexcrichton created PR review comment:

Cut-off comment?

Wasmtime GitHub notifications bot (Jan 28 2022 at 14:33):

alexcrichton created PR review comment:

To avoid confusing this with an actual benchmark, could this be placed at benches/common/mod.rs?

Wasmtime GitHub notifications bot (Jan 28 2022 at 14:33):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Feb 09 2022 at 22:00):

cfallin closed without merge PR #3736.

Last updated: Dec 23 2024 at 12:05 UTC