pulley: Is the best interpreter loop a "match" loop or a "tail call" loop? #9995
Description
Pulley currently has two methods of dispatch 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.