Of course it beats a native interpreter. WASM overhead is about 20%, interpreter overhead is about 1000%.
What's cool here is to have a GameBoy JIT runtime at all.
WATaBoy: JIT-Ing Game Boy Instructions to WASM Beats a Native Interpreter
11–20 of 45 posts
Re: WATaBoy: JIT-Ing Game Boy Instructions to WASM Beats a Native Interpreter
#12Of course it beats a native interpreter. WASM overhead is about 20%, interpreter overhead is about 1000%. What's cool here is to have a GameBoy JIT runtime at all.
It's two jits in total.
Re: WATaBoy: JIT-Ing Game Boy Instructions to WASM Beats a Native Interpreter
#13So it's a JIT-in-JIT? JiJIT?
Re: WATaBoy: JIT-Ing Game Boy Instructions to WASM Beats a Native Interpreter
#14yet on real old hardware it would be 20x slower in real life. same as all native javascript junk - its fast, but non usuable on older hardware
Here's a nickel kid. Go buy yourself a real computer.
Re: WATaBoy: JIT-Ing Game Boy Instructions to WASM Beats a Native Interpreter
#15Re: WATaBoy: JIT-Ing Game Boy Instructions to WASM Beats a Native Interpreter
#16I've always really enjoyed Andrew Kelley's article about trying to statically recompile NES code from 2013 [1]. Basically he makes a ton of progress but gets hung up not just on the realities of the handwritten assembler of the era just not being all that great at mapping to higher level LLVM IR. In the conclusion he specifically calls out a JIT-type methodology as probably being the way to go, where you live-recompile the hot paths when you have the runtime data required to actually understand them, and don't worry about the parts you can't.
Very cool to see something like that in action.
Re: WATaBoy: JIT-Ing Game Boy Instructions to WASM Beats a Native Interpreter
#17Still doesn't beat a natively-coded emulator. I got several that run faster on a 166MHz non-MMX Pentium than this emulator does on my Core Ultra i9.