Rendered at 11:48:09 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
josephg 11 hours ago [-]
Very cool!
How does the performance of this wasm interpreter compare to native execution? Are we getting close?
And you’re comparing against wasmtime.pulley, which is their optimising interpreter. How does it stack up against wasmtime’s cranelift compiler?
zyedidia 5 hours ago [-]
When I've measured this in the past I've seen Wasmtime's Cranelift compiler generating code that runs roughly 1.5x-1.9x slower than native (LLVM) on SPEC 2017 workloads, with x86-64 being closer to 1.5x and AArch64 closer to 1.9x. From what I recall, interpreter performance was generally more like 10x slower than native, with some workloads that involved heavy cryptography/SIMD being 30x slower.
herobird 3 hours ago [-]
Thank you! :)
In the `wasmi-benchmarks` suite we support ~20 different Wasm runtimes and compare their performance with each other, including optimizing JITs such as Wasmtime/Wasmer Cranelift and baseline JITs such as Wasmtime Winch and Wasmer Singlepass.
The geomean of performance of Wasmi compared to baseline JITs across all benchmarks in the repository ranges from 2.5-5.2x slower depending on hardware.
And compared to opimizing JITs geomean ranges from 5.3-10.7x slower.
Wasmtime's Pulley is a very interesting interpreter. It isn't the fastest but it is the only Wasm interpreter that sits behind an elaborate optimization pipeline. Thus if you feed unoptimized Wasm, it would likely outperform the other interpreters. However, unoptimized Wasm is extremely uncommon.
achierius 10 hours ago [-]
No, they're not getting close. Top performing Wasm runtimes (like those in V8 and JSC) are generally between 10% (for pure math workloads) and 2x (conservatively, for ef allocation heavy ones) the speed of equivalent native implementations. But that's including the JIT compilation tiers; the performance of interpreters alone lags by an order of magnitude.
paulddraper 10 hours ago [-]
Between 10% and 100% ? Am I understanding that right?
achierius 7 hours ago [-]
I put that poorly: read as 110% and 200%
Retro_Dev 5 hours ago [-]
Surely you mean the "time spent," not the "speed" - as an interpreter would have an overhead, not magically speed up WASM execution. Somewhat related note, we need better tools for PGO within native compiled programs.
herobird 3 hours ago [-]
hi, author here, ready to answer all your questions! (sorry for the delay, 2nd-chance post)
How does the performance of this wasm interpreter compare to native execution? Are we getting close?
And you’re comparing against wasmtime.pulley, which is their optimising interpreter. How does it stack up against wasmtime’s cranelift compiler?
The geomean of performance of Wasmi compared to baseline JITs across all benchmarks in the repository ranges from 2.5-5.2x slower depending on hardware. And compared to opimizing JITs geomean ranges from 5.3-10.7x slower.
Wasmtime's Pulley is a very interesting interpreter. It isn't the fastest but it is the only Wasm interpreter that sits behind an elaborate optimization pipeline. Thus if you feed unoptimized Wasm, it would likely outperform the other interpreters. However, unoptimized Wasm is extremely uncommon.