WebAssemblyはさらに高速：Firefoxの新しいストリーミングおよびマルチレベルコンパイラ

両方の著者：Lin Clarkは、Mozilla Developer Relationsグループの開発者です。 JavaScript、WebAssembly、Rust、およびServoに従事しており、コードに関する漫画も描いています。



WebAssemblyは、Webでのコード実行を高速化するため、このルールはゲームのルールを変更する要因と呼ばれています。 一部のアクセラレーションは既に実装されていますが 、他のアクセラレーションは後で表示されます。



1つの手法は、ブラウザがロード中にコードをコンパイルするストリーミングコンパイルです。 これまで、この技術は潜在的な加速オプションと考えられてきました。 しかし、Firefox 58のリリースにより、現実のものになります。



Firefox 58には2レベルのコンパイラも含まれています。 新しいベースコンパイラは、最適化コンパイラよりも10〜15倍速くコードをコンパイルします。



これら2つの変更により、ネットワークからのコードよりも速くコードをコンパイルできます。







デスクトップでは、1秒あたり30〜60 MBのWebAssemblyコードをコンパイルします。 これは、パケットを配信するネットワークよりも高速です 。



Firefox NightlyまたはBetaをお持ちの場合は、ご自身のデバイスでこの技術を試すことができます。 中規模のモバイルデバイスでも、コンパイルは8 MB /秒で実行されます。これは、ほとんどのモバイルネットワークのダウンロード速度よりも高速です。



つまり、ダウンロードが完了するとすぐにコードの実行が開始されます。

なぜこれが重要なのですか？

Webパフォーマンスの支持者は、Webページの読み込みを遅くするため、Webサイト上のJavaScriptの多くにとって重要です。



この速度低下の主な理由の1つは、解析時間とコンパイル時間です。 Steve Sowdersが指摘したように、Webボトルネックは以前はネットでしたが 、現在はCPU、つまり実行のメインスレッドでした。







そのため、メインスレッドから可能な限り多くの作業を取得する必要があります。 また、ページの対話性をできるだけ早く確保するため、CPUを常に使用します。 また、一般的にCPUの負荷を減らすことをお勧めします。



JavaScriptはこれらの目標のいくつかを達成できます。 ファイルを受信した後、メインストリームの外部のファイルを解析できます。 しかし、それらはまだ分解する必要があり、これは多くの作業です。 そして、コンパイルする前に解析が完了するのを待つ必要があります。 通常、 遅延 JS コンパイルがオンザフライで発生するため、コンパイルの場合はメインストリームに戻ります。







WebAssemblyを使用すると、最初から作業が少なくなります。 WebAssemblyのデコードは、JavaScriptの解析よりもはるかに簡単で高速です。 そして、これらのデコードとコンパイルはいくつかのスレッドに分割できます。



これは、複数のスレッドが基本的なコンパイルを実行し、大幅に高速化することを意味します。 プロセスの最後に、プリコンパイルされたコードがメインスレッドで実行され始めます。 JSの場合のように、コンパイルの待機を停止する必要はありません。







プリコンパイルされたコードはメインスレッドで実行されますが、現時点では他のスレッドが最適化されたバージョンで動作しています。 最適化されたバージョンの準備が整うと、予備バージョンが置き換えられ、コードがさらに高速に実行されます。



これにより、WebAssemblyの読み込みは、JavaScriptの読み込みよりも画像のデコードに似ています。 考えてみてください...パフォーマンスは150 KBを超えるバヨネットスクリプトを推奨していますが、このサイズの画像は満足のいくものではありません。







これは、「 JavaScriptの価格 」の記事でエディオスマニが説明したように、画像の読み込みがはるかに高速だからです。 また、画像のデコードはメインストリームをブロックしません。アレックスラッセルが記事「 それを買う余裕はありますか？ 」で説明したように リアルタイムのWebパフォーマンス予算 。



これは、WebAssemblyファイルが画像と同じ大きさになることを意味しません。 WebAssemblyツールの最初のバージョンは大きなファイルを作成しましたが、これはランタイムの大部分を含める必要があるためです。 サイズを縮小するための積極的な作業が進行中です。 たとえば、Emscriptenには「 プッシュイニシアチブ 」があります。 Rustでは、wasm32-unknown-unknownターゲットを使用して非常に小さなファイルを取得できるようになりました。 さらに、さらに最適化するためのwasm-gcやwasm-snipなどのツールがあります。



これは、WebAssemblyファイルが同等のJavaScriptよりもはるかに高速にロードされることを意味します。



これは非常に重要です。 Yehuda Katzが指摘したように 、これはゲームのルールを実際に変える要因です。



それでは、新しいコンパイラがどのように機能するかを見てみましょう。

ストリームのコンパイル：初期のコンパイル

コードのコンパイルを開始するほど、コードを早く終了します。 これは、ストリーミングコンパイルが行うことです... .wasmファイルをできるだけ早くコンパイルし始めることによって。



ファイルをダウンロードするとき、ファイルは1つにまとめられていません。 代わりに、一連のパッケージで提供されます。



以前は、.wasmファイルのすべてのパッケージをダウンロードする必要があり、その後ブラウザーのネットワーク層がそれをArrayBufferに配置しました。







次に、このArrayBufferはWeb VM（別名JSエンジン）に転送されました。 この時点で、WebAssemblyコンパイラーはコンパイルを開始します。







しかし、コンパイラーを保留にする正当な理由はありません。 WebAssemblyを1行ずつコンパイルすることは技術的に可能です。 そのため、最初のフラグメントが到着した後にプロセスを開始できます。



これはまさにコンパイラーが行うことで、WebAssemblyストリーミングプログラミングインターフェイスを利用しています。







ResponseオブジェクトをWebAssembly.instantiateStreaming



渡すと、ダウンロード後すぐに新しいコードフラグメントがWebAssemblyエンジンに送られます。 その後、次のフラグメントがまだダウンロードされている間に、コンパイラは最初のフラグメントで作業を開始できます。







コードを同時にダウンロードしてコンパイルすることに加えて、別の利点があります。



.wasmモジュールのコードセクションは、データの残りの部分（モジュールのメモリオブジェクトに配置される）の前に始まります。 そのため、ストリーミングコンパイルの場合、モジュールデータが最後までダウンロードされていない間にコードがコンパイルされます。 モジュールに大量のデータが必要な場合、メモリオブジェクトのサイズは数メガバイトになる可能性があり、ストリームコンパイルによりパフォーマンスが大幅に向上します。







ストリーミングコンパイルでは、コンパイルプロセスが早く開始されます。 しかし、より速くすることもできます。

レベル1コアコンパイラ：コンパイル速度

高速なコードが必要な場合は、最適化する必要があります。 しかし、コンパイル中にこれらの最適化を行うには時間がかかり、コンパイル自体が遅くなります。 したがって、これは明確な妥協です。



ただし、2つのコンパイラを使用すると、高速コンパイルと最適化されたコードの両方の利点を得ることができます。 最初のものは特別な最適化なしで迅速にコンパイルされ、2番目のものはより遅く動作しますが、より最適化されたコードを生成します。



これは階層化コンパイラと呼ばれます。 コードが最初に到着すると、レベル1コンパイラー（またはベースコンパイラー）によってコンパイルされます。 基本コンパイラーによってコンパイルされたコードが開始された後、レベル2コンパイラーはコードを再度処理し、バックグラウンドでより最適化されたバージョンを準備します。



プロセスが完了すると、コードの基本バージョンは最適化されたバージョンとホットスワップされます。 これにより、コードの実行が高速化されます。







JavaScriptエンジンは、長い間マルチレベルコンパイラを使用してきました。 ただし、JSエンジンは、「ホット」コードに対してのみレベル2コンパイラ（つまり、最適化）を使用します...これは、実行のためによく呼び出されます。



対照的に、WebAssemblyでは、レベル2コンパイラーは完全に再コンパイルを実行し、モジュールコード全体を最適化します。 将来的には、最適化をどのように貪欲または怠zyにするかを制御するオプションを追加することができます。



基本的なコンパイラは、ロードにかかる時間を大幅に節約します。 最適化コンパイラよりも10〜15倍高速に実行されます。 そして、私たちのケースでコンパイルされたコードは、2倍遅いだけです。



つまり、最適化されていない基本バージョンのみが機能している最初の瞬間でも、コードは十分に高速に機能します。

並列化：さらに高速化

Firefox Quantumの記事で 、粗調整と微調整の並列化のオプションについて説明しました。 両方のタイプを使用してWebAssemblyをコンパイルします。



前述のように、最適化コンパイラはバックグラウンドで実行され、メインスレッドをコード実行用に解放します。 最適化コンパイラが再コンパイルを実行している間、基本的なコンパイル済みバージョンが機能する場合があります。



ただし、この場合、ほとんどのコンピューターでは、ほとんどのコアがアンロードされたままです。 すべてのコアを最適に使用するために、両方のコンパイラは微調整された並列化を使用して作業を分離します。



並列化ユニットは関数です。 各関数は、個別のカーネルで個別にコンパイルできます。 実際、これは非常に微調整されているため、実際にはこれらの機能をより大きな機能グループにグループ化する必要があります。 これらのグループは異なるコアに送信されます。

...そして、完全なキャッシュのためにこの作業をすべてスキップします（将来）

現在、ページをリロードするたびに、デコードとコンパイルが繰り返し実行されます。 ただし、同じ.wasmファイルがある場合は、同じマシンコードにコンパイルする必要があります。



したがって、ほとんどの場合、この作業はスキップできます。 それが私たちが将来することです。 デコードとコンパイルは最初のページの読み込み時に実行され、結果のマシンコードはHTTPキャッシュに保存されます。 次に、このURLの要求に応じて、すぐにプリコンパイルされたマシンコードが発行されます。



そのため、通常、後続のページの読み込みでは読み込み時間がなくなります。







この機能の基盤はすでに構築されています。 Firefox 58では、この方法でJavaScriptバイトコードをキャッシュします。 .wasmファイルをサポートするために、この機能を拡張するだけです。