bytecodealliance / bytecodealliance/wasmtime
pulley: Is the best interpreter loop a "match" loop or a "tail call" loop?
- Dominant language
- Rust
- Stars
- 18.6k
- Forks
- 1.8k
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 121
Description
Pulley currently has [two methods of dispatch](https://github.com/bytecodealliance/wasmtime/blob/54385f8694e9ea736106050c69fc2822e6bd5fb6/pulley/src/interp.rs#L17-L20) in the interpreter loop, namely one morally using a giant `match` statement and the other using tail-calls between opcodes. The latter is currently only evaluatable on some architectures (e.g. x64) when optimizations are turned on and LLVM optimizes things right. Rust's `become` keyword does not currently work in Nightly.
I just did a Sightglass run of these two methods of dispatch in the interpreter and I got:
```
execution :: cycles :: benchmarks/pulldown-cmark/benchmark.wasm
Δ = 14835771.96 ± 525589.74 (confidence = 99%)
match.so is 1.17x to 1.19x faster than tail.so!
[81442196 82553273.83 87049480] match.so
[96420118 97389045.79 102479551] tail.so
execution :: cycles :: benchmarks/bz2/benchmark.wasm
Δ = 104438181.93 ± 1644379.63 (confidence = 99%)
match.so is 1.13x to 1.13x faster than tail.so!
[782662505 787350365.15 795150499] match.so
[888116768 891788547.08 916663514] tail.so
execution :: cycles :: benchmarks/spidermonkey/benchmark.wasm
Δ = 674804802.30 ± 21521230.61 (confidence = 99%)
tail.so is 1.03x to 1.04x faster than match.so!
[19395106358 19464509629.23 19638165876] match.so
[18716347537 18789704826.93 18999413981] tail.so
```
which I found surprising. The "match" loop was 10-20% faster for bz2/pulldown-cmark where the "tail" loop was only 3-4% faster for spidermonkey. This goes against what I've been measuring on a "fib" micro-benchmark where the "tail" loop is about 20% faster.
This leads me to the conclusion of "I don't know what's going on here" and I wanted to open an issue on this. It's not a maintenance burden at this time to have both implementations, but ideally we wouldn't have two indefinitely.
Contributor guide
Assessment
This issue has not been assessed yet.