Game Boyを爆速化！JITコンパイルでWASMへ変換する「WATaBoy」が凄すぎる

Game Boyの命令セットを直接WASM（WebAssembly）へJITコンパイルすることで、従来のネイティブインタープリタ方式を凌駕するパフォーマンスを実現した「WATaBoy」の紹介です。

すごく面白い記事だね。ネイティブインタプリタとiOS上のJIT-on-WASMの比較も見てみたかったな。

学部生が手がけたプロジェクトとしては信じられないほど素晴らしいね。かなり感動した。FirefoxがChromeやSafariより25%も遅いっていう結果は興味深いね。なぜなんだろう？

そりゃネイティブインタプリタより速いのは当然だよ。WASMのオーバーヘッドは約20%だけど、インタプリタは1000%くらいあるからね。ここで重要なのは、GameBoyのJITランタイムを動かせたっていう事実そのものだよ。

それってJIT-in-JITってこと？JiJITとか？

2013年にAndrew Kelleyが書いた、NESコードを静的に再コンパイルしようとした記事 [1] はずっと大好きだったんだ。彼はかなりの成果を出したんだけど、当時の手書きアセンブラはLLVM IRのような高レベルなものへの変換と相性が悪くて、結局行き詰まってしまった。彼は結論で、実行時にデータが得られるホットパスだけを再コンパイルするJITの手法こそが現実的で、そうでない部分は気にしなくていいって指摘してるんだよね。実際にそれが動いているのを見られるのはすごくクールだ。 [1]: https://andrewkelley.me/post/jamulator.html (https://andrewkelley.me/post/jamulator.html)

それでもネイティブコードで書かれたエミュレータには勝てないよ。俺が持ってるエミュレータは、166MHzのMMXなしPentiumでも、このエミュレータがCore Ultra i9で動くより速く動作するぞ。

iOSではJITコンパイルができないからDolphinはiOSに存在しない…。まあ、AppleにはJIT制限の例外が一つだけあって、それがWebブラウザなんだ。WebKitのJavaScriptエンジンであるJavaScriptCoreは、高性能化のためにJITコンパイルを使っている。だからJS関数が何度も呼び出されれば、最終的に最適化されてネイティブマシンコードにコンパイルされる。WebAssemblyも同じこと。ヘッドラインの理由がずっと気になっていたんだけど、これは本当に面白い回答だ。制限を回避する見事な方法だね。他のプロジェクトにも応用できるのか気になるところ。

著者の基本的な前提と、このプロジェクトに取り組むきっかけになった動機は間違ってるよ。 https://github.com/StephenDev0/StikDebug (https://github.com/StephenDev0/StikDebug) 学部生のプロジェクトとしては、良い成績を取るために既存の解決策の存在を都合よく忘れるのもアリってことかな。

めちゃくちゃ面白い！16年前の修士課程で、仮想マシンの授業中にDolphinとLLVMを使って同じようなことをやったよ。インタプリタをLLVMビットコードにコンパイルして、それを使って基本ブロックを構築したんだ。めちゃくちゃ遅かったけどちゃんと動いたし、作業していてすごく楽しかったな。