Stream: git-wasmtime

Topic: wasmtime / Issue #2437 Introduce benchmarking API

Wasmtime GitHub notifications bot (Nov 20 2020 at 19:55):

abrown commented on Issue #2437:

I created a draft based on @fitzgen's comment re: a Wasmtime benchmark dylib. I don't really expect this to be the final product but I wanted to make sure that I could use the API we discussed over in sightglass (and what better way to know than to actually build it?). I am not quite sure about:

• there are a lot of unsafe bits here due to the C FFI and I would appreciate someone verifying that I didn't miss something
• having the "bench" "start"/"end" functions have a signature of fn() is very convenient for the benchmarks but I will need to be very careful in Sightglass that the measurement state, e.g. the start time, is handled safely.

Wasmtime GitHub notifications bot (Dec 01 2020 at 08:21):

jlb6740 commented on Issue #2437:

The new crate introduced here, wasmtime-bench-api, creates a shared library, e.g. wasmtime_bench_api.so, for executing Wasm benchmarks using Wasmtime. It allows us to measure several phases separately by exposing engine_compile_module, engine_instantiate_module, and engine_execute_module, which pass around an opaque pointer to the internally initialized state. This state is initialized and freed by engine_create and engine_free, respectively. The API also introduces a way of passing in functions to satisfy the "bench" "start" and "bench" "end" symbols that we expect Wasm benchmarks to import. The API is exposed in a C-compatible way so that we can dynamically load it (carefully) in our benchmark runner.

Hi @abrown, to be clear, so this is adding a crate that when built will build a shared library that includes everything for embedding enough of the wasmtime runtime into whatever (sightglass for example) for instantiating and running a wasm file? Doesn't the c-api already expose api's to load and instantiate and execute modules? If so, what are the notable differences with what's here? Also the bench_start and bench_end .. if someone has a C program or rust files and want to add these markers around a specific function and recompile to wasm .. how is this shared library that is produced here used in that process?

Wasmtime GitHub notifications bot (Dec 01 2020 at 20:38):

abrown commented on Issue #2437:

this is adding a crate that when built will build a shared library that includes everything for embedding enough of the wasmtime runtime into whatever (sightglass for example) for instantiating and running a wasm file?

Yes.

Doesn't the c-api already expose api's to load and instantiate and execute modules? If so, what are the notable differences with what's here?

It does, but this is quite a bit simpler. I did create bindings to use the Wasm C API from Rust but this was quite a bit more work than this approach (a lot of unsafe things are yet to be figured out there). Either way is fine with me.

Also the bench_start and bench_end .. if someone has a C program or rust files and want to add these markers around a specific function and recompile to wasm .. how is this shared library that is produced here used in that process?

This shared library is decoupled from that completely. That way benchmarks can be created apart from how they are run. There is an example of how this works here

Wasmtime GitHub notifications bot (Dec 01 2020 at 20:38):

abrown edited a comment on Issue #2437:

this is adding a crate that when built will build a shared library that includes everything for embedding enough of the wasmtime runtime into whatever (sightglass for example) for instantiating and running a wasm file?

Yes.

Doesn't the c-api already expose api's to load and instantiate and execute modules? If so, what are the notable differences with what's here?

It does, but this is quite a bit simpler. I did create bindings to use the Wasm C API from Rust but this was quite a bit more work than this approach (a lot of unsafe things are yet to be figured out there). Either way is fine with me.

Also the bench_start and bench_end .. if someone has a C program or rust files and want to add these markers around a specific function and recompile to wasm .. how is this shared library that is produced here used in that process?

This shared library is decoupled from that completely. That way benchmark artifacts can be created apart from how they are run. There is an example of how this works here

Last updated: Oct 23 2024 at 20:03 UTC