Fix the WATT_JIT feature #48
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was curious to see the impact of Wasmtime's recent development since I
last added the
WATT_JIT
env var feature towatt
a few years agosince quite a lot has changed about Wasmtime in the meantime. The
changes in this PR account for some ABI changes which have happened in
the C API which doesn't account for anything major.
Taking my old benchmark of
#[derive(Serialize)]
onstruct S(f32, ... /* 1000 times */)
the timings I get for the latestversion of
serde_derive
are:Using instead
#[derive(Serialize)] struct S(f32)
the timings I get are:So for large inputs jit-compiled WebAssembly can be faster than the
native
serde_derive
when serde is itself compiled in debug mode. Notethat this is almost always the default nowadays since
cargo build --release
will currently build build-dependencies with nooptimizations. Only through explicit profile configuration can
serde_derive
be built in optimized mode (as I did to collect theabove numbers).
The
watt (cached)
column is where I enabled Wasmtime's globalcompilation cache to avoid recompiling the module every time the
proc-macro is loaded which is why the timings are much lower. The
difference between
watt
andwatt (cached)
is the compile time of themodule itself. The 40ms or so in
watt (cached)
is almost entirelyoverhead of loading the module from cache which involves decompressing
the module from disk and additionally sloshing bytes around. More
efficient storage mediums exist for Wasmtime modules which means that it
would actually be pretty easy to shave off a good chunk of time from
that. Additionally Wasmtime has a custom C API which significantly
differs from the one used in this repository which would also be
significantly faster for calling into the host from wasm. Of the current
~3ms runtime in wasm itself that could probably be reduced further with
more optimized calls.
Overall this seems like pretty good progress made on Wasmtime in the
interim since all my initial work in #2. In any case I wanted to post
this to get the
WATT_JIT
feature at least working again sinceotherwise it's segfaulting right now, and perhaps in the future if
necessary more perf work can be done!