Stream: git-wasmtime

Topic: wasmtime / PR #5274 bench: benchmark several common WASI ...


view this post on Zulip Wasmtime GitHub notifications bot (Nov 15 2022 at 22:23):

abrown opened PR #5274 from bench-wasi to main:

In order to properly understand the impact of providing thread-safe
implmentations of WASI contexts (https://github.com/bytecodealliance/wasmtime/issues/5235), we need benchmarks that measure
the current performance of WASI calls using Wiggle. This change adds
several common WASI scenarios as WAT files (see benches/wasi/*.wat)
and benchmarks them with criterion. Using criterion's iter_custom,
the WAT file runs the desired number of benchmark iterations internally
and the total duration of the runs is divided to get the average time
for each loop iteration.

Why WAT? When compiling these benchmarks from Rust to wasm32-wasi, the
output files are large, contain other WASI imports than the desired
ones, and overall it is difficult to tell if we are measuring what we
expect. By hand-writing the WAT, it is (slightly) more clear what each
benchmark is doing.
@abrown
abrown committed

view this post on Zulip Wasmtime GitHub notifications bot (Nov 15 2022 at 22:23):

abrown edited PR #5274 from bench-wasi to main:

In order to properly understand the impact of providing thread-safe
implmentations of WASI contexts (https://github.com/bytecodealliance/wasmtime/issues/5235), we need benchmarks that measure
the current performance of WASI calls using Wiggle. This change adds
several common WASI scenarios as WAT files (see benches/wasi/*.wat)
and benchmarks them with criterion. Using criterion's iter_custom,
the WAT file runs the desired number of benchmark iterations internally
and the total duration of the runs is divided to get the average time
for each loop iteration.

Why WAT? When compiling these benchmarks from Rust to wasm32-wasi, the
output files are large, contain other WASI imports than the desired
ones, and overall it is difficult to tell if we are measuring what we
expect. By hand-writing the WAT, it is (slightly) more clear what each
benchmark is doing.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 15 2022 at 22:33):

jameysharp submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 15 2022 at 22:33):

jameysharp submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 15 2022 at 22:33):

jameysharp created PR review comment:

            // `instantiate` for details).

view this post on Zulip Wasmtime GitHub notifications bot (Nov 15 2022 at 22:33):

jameysharp created PR review comment:

Since all the type parameters are the _ wildcard, is the ::<_, _, _> necessary? I'd have guessed "no", but I don't know.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 15 2022 at 23:40):

abrown updated PR #5274 from bench-wasi to main.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 15 2022 at 23:41):

abrown submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 15 2022 at 23:41):

abrown created PR review comment:

Good point, fixed...

view this post on Zulip Wasmtime GitHub notifications bot (Nov 16 2022 at 01:01):

abrown has marked PR #5274 as ready for review.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 16 2022 at 01:02):

abrown merged PR #5274.


Last updated: Nov 22 2024 at 16:03 UTC