Wasmi の新しい実行エンジン – これまで以上に高速

数か月にわたる研究、開発、品質保証を経て、Wasmi のこれまでで最も重要なアップデートがついに実稼働環境で使用できるようになりました。

ワスミ 効率的で多用途な Webアセンブリ (Wasm) 組み込み環境に重点を置いたインタープリター。プラグイン システム、クラウド ホスト、スマート コントラクト実行エンジンとして最適です。

Wasmi は、ベストエフォートベースで Wasmtime API を意図的にミラーリングしており、ドロップイン置換またはプロトタイピングランタイムとして最適です。

インストール WasmiのCLIツール 経由 cargo install wasmi_cli またはライブラリとして wasmi 木箱。

Wasmi v0.32 には、レジスタベースのバイトコードを利用する新しい実行エンジンが搭載されており、実行パフォーマンスが最大 5 倍向上します。さらに、遅延コンパイルやその他の新しい技術により、起動パフォーマンスが数桁向上しました。

の v0.32の変更履歴 は非常に大きく、次のセクションでは最も重要な変更点について説明します。

ワスミは 書き換えインタープリタつまり、受信した WebAssembly バイトコードを、効率的な実行パフォーマンスを目的とした Wasmi 独自の内部バイトコードに書き換えることになります。

この書き直しを私たちは コンパイル または 翻訳 インタープリタで。これは、Wasmi インタープリタ自体のコンパイルと混同しないでください。

Wasmi にとって翻訳速度が重要なのはなぜですか?

高速変換により、最初の命令が実行されるまでにかかる時間である起動時間が短縮されます。

インタープリターとしての Wasmi は、当然ながら起動時間が短くなるように最適化されているため、Wasm バイナリの変換に必要な時間が実行に必要な時間を超えるような、変換を集中的に行うワークロードに適しています。
逆に、実行時間が変換時間を上回る計算集約型のワークロードは、次のようなJITベースのWasmランタイムによってより適切に処理されます。 ワズムタイム、 ワムル、 または ワスマー。

怠惰な翻訳

特に新しいレジスタベースのバイトコードでは、変換にコストがかかる場合があります。これに対処するために、実行に必要な Wasm バイナリの部分のみを変換する遅延変換が実装されました。

Wasmi は 3 つの異なる翻訳モードをサポートしています。

• Eager: コードは事前に積極的に検証され、積極的に翻訳されます。
  • 注記： これは Wasmi v0.32 のデフォルト モードです。
• Lazy: コードは遅延翻訳され、遅延検証されます。
  • 注記： 1 つの欠点は、これにより、より広範な Wasm コミュニティ内で議論の的となっている、部分的に検証された Wasm モジュールが許可されることです。
• LazyTranslation: コードは遅延翻訳されますが、熱心に検証されます。
  • 注記： より遅いが Lazy これにより、部分的に検証された Wasm モジュールの問題が修正されます。

ライブラリとしての利用

let mut c = wasmi::Config::default();
c.compilation_mode(wasmi::CompilationMode::Lazy);

WasmiのCLIでの使用

Wasmi CLIはコマンドラインオプションをサポートするようになりました --compilation-mode= どこ の一つであります eager、 lazy、 または lazy-translation。

未確認の翻訳

WasmiはWasmバイナリを検証します。これは起動フェーズで費やされる合計時間の約20～40%を占めます。しかし、一部のユーザーは、使用されるWasmバイナリが事前に検証されていることを事前に知っているため、Wasm検証を完全にスキップしたい場合があります。これは、 unsafe fn Module::new_unchecked API。

非ストリーミング翻訳

Wasmi v0.31 以前では、Wasm 入力を処理するために常にストリーミング変換が使用されていました。しかし、実際にはほとんどのユーザーはこれを使用しなかったので、v0.32 では Wasmi はデフォルトで非ストリーミング変換を使用し、パフォーマンスがさらに向上しました。

実際にストリーミング翻訳を利用したいユーザーは、新しい Module::new_streaming ニーズに合わせた API。

リンカーキャッシュ

ワスミ Linker Wasm バイナリがホストと通信するために使用できるホスト関数のセットを定義するために使用されます。多くの場合、数十のホスト関数が定義され、すぐにコストがかさむ可能性があります。

これを解決するため、ワスミは LinkerBuilder、これにより、新しいインスタンスを効率的に作成できます Linker初期セットアップ後。

50 個の定義されたホスト関数を使用したベンチマークでは、このアプローチを使用することで 120 倍の高速化が実証されています。

ベンチマーク

上記のすべてのテクニックを組み合わせることで、以前の Wasmi v0.31 と比較して、Wasmi の起動時間を数桁高速化できます。

この記事の執筆時点では、すべての Wasm ランタイムの最新バージョンが使用されています。 ^。

現在、ウインチは以下をサポートしています x86_64 プラットフォームであるため、それらのシステムでのみテストされました。

ERC-20 – 7KB

アルゴン2 – 61KB

BZ – 147KB

プルダウン-Cマーク – 1.6MB

スパイダーモンキー – 4.2MB

FFMPEG – 19.3MB

注記： Wasmtime (Cranelift) がタイムアウトし、Stitch はコンパイルに失敗しました ffmpeg.wasm。

翻訳ベンチマーク：結論

WasmiとWasm3は、遅延コンパイル機能のおかげで、圧倒的に優れたパフォーマンスを発揮します。予想通り、WasmtimeやWasmerのようなJITベースのWasmランタイムの最適化は、このコンテキストではパフォーマンスが低下します。高速起動用に設計されたシングルパスJITは、 ウインチ そして ワスマーシングルパスも大幅に遅くなります。遅延翻訳を使用しているにもかかわらず、 ステッチの翻訳パフォーマンスは理想的ではありません。ただし、Winch と Stitch はどちらもまだ開発の実験段階にあり、改善が期待できることに留意することが重要です。

実行速度

実行エンジンにとって、計算速度は当然ながら最も重要です。残念ながら、古い Wasmi v0.31 ではこの点に関して改善の余地が大いにありました。

レジスタベースのバイトコード

古い Wasmi v0.31 は、実行を駆動するために内部的にスタックベースの中間表現 (IR) を使用します。この IR は WebAssembly バイトコードに似ているため、変換時間が短縮されます。

スタックベースの IR は通常、レジスタベースの IR と同じ問題を表すために、より多くの命令を使用します。 ^{ただし、インタープリタのパフォーマンスは主に命令のディスパッチによって決まります。したがって、実行される命令がそれぞれ複雑であっても、実行する命令の数を減らすことは通常は良いトレードオフです。}

このため、バージョン 0.32 以降の Wasmi では、実行を制御するためにレジスタベースの IR が使用されるようになりました。

メモリ消費量

新しいレジスタベースの IR は、実行パフォーマンスを向上させ、メモリ使用量を最小限に抑えるように慎重に設計されました。Wasm バイナリの大部分はエンコードされた命令で構成されているため、Wasmi を介して Wasm を実行すると、メモリ使用量が大幅に削減され、キャッシュ効率が向上します。

ベンチマーク

この記事の執筆時点では、すべての Wasm ランタイムの最新バージョンが使用されています。 ^。

フィボナッチ（反復） – Compute Intense

フィボナッチ（再帰的） – Call Intense

このテストケースでは、Wasmi v0.32 は v0.31 と比べて大幅に改善されていません。これは、Wasmi v0.31 がすでに比較的高速であったことと、新しいレジスタベースのバイトコードが、呼び出し集中型ワークロードよりも計算集中型ワークロードを優先していることが一因です。ほとんどの Wasm プロデューサー (LLVM など) は積極的なインライン化により計算集中型ワークロードを生成するため、これは通常、適切なトレードオフです。

プライム – バランス

行列の乗算 – メモリを重視

興味深いことに、Wasmer (Singlepass) は、Apple シリコン上で、一部のインタープリターよりもさらに遅くなるという問題を抱えているようです。

アルゴン – ハッシュ計算

注記： スティッチとウィンチは実行できなかった argon2.wasm テストケース。

次の表は、CPU ごとの Wasm インタープリターの Coremark スコアを示しています。

実行ベンチマーク: 結論

Wasmi は AMD サーバー チップでは特に強力ですが、Apple シリコンでは遅れをとっています。この理由としては、使用されている命令ディスパッチの手法の違いが考えられます。

Stitch インタープリタのパフォーマンスは非常に優れています。その理由は、Rust がサポートしていないにもかかわらず、Stitch が LLVM オプティマイザに命令ディスパッチの末尾呼び出しを生成するように促しているためと考えられます。さまざまな欠点があるため、この設計上の決定は Wasmi v0.32 の開発中に議論され、却下されました。 ^{特に Apple シリコンと Windows プラットフォームにおける Stitch の優れた実行パフォーマンスを考えると、これらの決定は再評価されるべきです。}

紛らわしいことに、Intel i7 14700K のテスト ケースにおける Wasmi の優れた結果は、Coremark スコアには反映されていません。これはおそらく、Coremark を含むすべてのテスト ケースが、ある程度、ある種のワークロードに偏っているためです。

ベンチマークスイート

上記のベンチマークとプロットは、 wasmi-benchmarks リポジトリ。読者はベンチマークを実行し、自分のコンピュータで結果をプロットして、主張を確認または反証することをお勧めします。使用方法は wasmi-benchmarksの README.md。

Wasm ランタイムの追加、プロットの改善、新しいテスト ケースの追加などの貢献を歓迎します。

この記事では、新しい Wasmi バージョン 0.32 のハイライトを紹介し、さまざまなテスト ケースを通じて起動と実行のパフォーマンスが大幅に向上したことを実証しました。

この新しいメジャーアップデートにより、Wasmiは将来の開発に向けた強固な基盤を手に入れました。 WebAssembly の提案 例えば multi-memory、 simd そして gc Wasmi v0.32 の開発のために保留されていた提案は、実装を待っています。

特に AMD サーバー チップでの有望な結果は、Wasmi に大きな可能性があることを示す適切な指標です。Apple シリコンでの Wasmi のパフォーマンスは、今後のリリースで改善される予定です。

実施計画が進行中である。 Wasm C-APIこれによって、C とインターフェースできるさまざまなエコシステムが Wasmi をライブラリとして使用できるようになります。

Wasmi は、優れた起動パフォーマンスと、特に組み込み環境に適した低メモリ消費量を備えた、効率的で多用途な Wasm インタープリターとしての地位を今後も強化していきます。

• まず第一に感謝したいのは パリティテクノロジーズ 長年にわたりWasmiの開発に資金を提供し、支援し、Wasmiが独立したプロジェクトとなることを可能にしてくれたことに感謝します。

• さらに、私は感謝の意を表したい。 神Wasmi に WASI preview1 サポートを実装するために時間と労力を費やしてくれた方々、本当に素晴らしい方々でした。

• さらに、感謝したいのは ヤムトは、Wasmランタイムベンチマークプラットフォームで私にインスピレーションを与えてくれました。ぜひチェックしてみてください。 おもちゃ Wasmインタープリター！

• 最後に、 ネオパラウム Rustにおける効率的なインタープリタディスパッチ技術について、考えさせられる議論や実験を共有してくれたことに感謝します。彼のWasm実験の1つをぜひチェックしてみてください。 s1vm。