Mozilla HacksのWhat makes WebAssembly fast?を読みました。WebAssemblyの速さを、JavaScript JITが抱える投機的最適化や脱最適化との対比で説明する記事です。
WebAssemblyは単に「低レベルだから速い」という話ではありません。この記事では、JavaScriptの実行パイプラインとWebAssemblyの実行パイプラインを並べ、パース、コンパイル、最適化、再最適化のコストがどこで減るのかを丁寧に見ています。
記事の要点
- JavaScriptは柔軟な言語なので、エンジンは実行しながら型やコードの使われ方を観察し、JITで最適化します。
- JITは強力ですが、型やオブジェクト形状の仮定が外れると、最適化済みコードを捨てて脱最適化する必要があります。
- WebAssemblyは最初から低レベルで型付きの形式なので、エンジンが実行時に推測する量を減らせます。
.wasmはJavaScriptより構造化されたバイナリ形式なので、パースやデコードがしやすく、並列コンパイルにも向いています。- 最適化の余地は残しつつも、JavaScriptほど実行中の観察と仮定に依存しないため、性能が読みやすくなります。
- 記事は、WebAssemblyがJavaScriptを置き換えるというより、性能が重要な部分を補完するものとして位置づけています。
参照リンクから見えたこと
記事内で参照されているJITコンパイラの解説記事も確認しました。そこでは、JavaScriptエンジンがコードを監視し、warm/hotになった部分をbaseline compilerやoptimizing compilerへ送る流れが説明されています。つまりJavaScriptの高速化は、実行時に集めた情報へ強く依存しています。
一方、前回紹介したWebAssembly modulesの記事では、WebAssemblyが概念機械向けの低レベルなmoduleとして説明されていました。今回の記事は、そのmodule形式がなぜ実行エンジンにとって扱いやすいのかを、実行パイプラインの面から補足しています。
さらに、次回記事としてリンクされているWhere is WebAssembly now and what’s next?は、当時のWebAssemblyがどこまで標準化・実装されていたのかを整理する位置づけです。速さの理由を理解したあとに、実際の普及状況へ進むシリーズ構成になっています。
気づき
今回の気づきは、WebAssemblyの速さは「最高速度」だけでなく「予測しやすさ」にあることです。JavaScript JITは実行時の観察で大きく速くなれますが、仮定が外れると脱最適化が起きます。WebAssemblyは最初からエンジンへ多くの情報を渡すため、速いだけでなく、性能のばらつきを減らせる設計になっています。
コメントを残す