Wasmer 5.0 リリース

 (wasmer.io)
8 ポイント 投稿者 GN⁺ 2024-11-03 | 1件のコメント | WhatsAppで共有

新しい実験的バックエンド

  • V8、Wasmi、WAMR のサポートが追加
  • これにより、Wasm-C-API 仕様をサポートするあらゆるインタープリタまたはランタイムを Wasmer に容易に統合可能
  • V8 統合により、V8 デバッガおよび Chrome Devtools を通じた優れたデバッグ体験を提供
  • V8 をバックエンドとして使用することは、WebAssembly の例外処理およびガベージコレクションをネイティブにサポートすることも意味する

iOS サポート（WAMR、Wasmi、V8 バインディングを通じて提供）

  • Wasmer は新しいインタープリタモードを通じて iOS デバイスに WebAssembly を提供
  • V8、Wasmi、WebAssembly Micro Runtime（WAMR）の機能を活用し、開発者は iOS 上で WebAssembly モジュールをシームレスに実行可能
  • コードベースへの変更は不要で、Apple エコシステムで高性能なアプリケーションを作成できるようになった

コードベースのスリム化

  • Wasmer 5.0 の公開に向けて、Wasmer のコードベースを可能な限りスリムにすることに注力
  • Wasmer で使用している一部の依存関係は長らくメンテナンスされていないか、より新しく安全なクレートによって置き換え可能だった
  • この 2 年間で Emscripten バインディングはほとんど使われていなかったため、サポートを終了して依存関係を整理した結果、Wasmer のコードベースから純粋に 2 万行のコードが削除された

パフォーマンス向上

  • モジュールの逆シリアライズは、最大 50% 高速化（つまり、Module::deserialize を呼び出すとき、または wasmer run を通じてモジュールを実行するとき）
  • これらの改善は、モジュールの逆シリアライズに使用されるゼロコピー逆シリアライズライブラリ rkyv の重要なアップデートを活用している

アップグレードされたコンパイラ: Cranelift と LLVM 18

  • 最新の Cranelift 統合によりランタイム速度が大幅に向上し、WebAssembly モジュールはこれまで以上に高速に実行される
  • Wasmer 5.0 には LLVM の最新バージョン（18）が含まれ、開発者はツールチェーンの最新最適化を利用可能
  • LLVM のアップグレードは互換性と性能を向上させ、複雑な WebAssembly モジュールのコンパイルと実行のための強固な基盤を提供
  • Wasmer 5.0 は、実験的な LoongAarch64 サポートも提供
  • 最新バージョンのコンパイラで coremark をベンチマークした結果、LLVM と Cranelift は Wasmer v4.4.0 と比べて v5.0 で約 8% 高速

GN⁺ の見解

  • Wasmer 5.0 の公開は、WebAssembly エコシステムにおける大きなマイルストーンになりそうだ。特に iOS サポートと多様なバックエンドオプションの提供は、WebAssembly の適用範囲をモバイルアプリケーションにまで大きく拡張することが期待される
  • V8、Wasmi、WAMR など多様なランタイムをバックエンドとしてサポートすることで、開発者は自分の要件に最適なランタイムを選べるようになった。これは WebAssembly の柔軟性と互換性を高めるうえで大きく貢献しそうだ
  • コードベースのスリム化と最新コンパイラ導入による性能最適化の取り組みも注目に値する。これは Wasmer が単なる機能追加にとどまらず、継続的な品質改善にも力を注いでいることを示している
  • 一方で Emscripten バインディングのサポート終了は惜しまれるが、WASI や WASIX など新しい標準の登場によってその必要性が低下している点を踏まえると、合理的な選択に見える
  • 総合すると Wasmer 5.0 は WebAssembly の進化をよく示すリリースであり、今後も Wasmer が WebAssembly エコシステムを主導する主要プロジェクトの一つであり続けると見込まれる。ただし、まだ実験段階にある機能の安定性と成熟度を高めるための継続的な努力は必要そうだ

関連記事

1件のコメント

 
GN⁺ 2024-11-03

Hacker Newsのコメント

  • パフォーマンスグラフが混乱していて、呪われているように見える。対数スケールで表示されているものもあり、何を伝えたいのか理解しづらい場合がある。たとえば「Argon 2」というグラフは、ほとんどすべての棒が同じ長さに見えるのに、個々の棒にはミリ秒単位で異なる数値が表示されている。
  • V8をバックエンドとして使うことで、WebAssemblyの例外処理とガベージコレクションをサポートするようになる。これに関連するさらなるニュースを期待している。wasm-gcが同じランタイム内で別のモジュール間においてホストデータや文字列を共有できるのか、それとも単一モジュールに限定されるのか気になる。
  • Wasmerのランディングページでは、何をしているのか理解しづらい。あらゆるものをどこでも実行すると言っているが、実際に何をするのかは明確ではない。開発者向けの製品に見えるが、技術的な説明よりバズワードが多い。
  • Wasmtimeには満足しており、WASMコンポーネントモデルとWASIベースのプラグインシステムをいじっている。楽しく作業している。
  • まだWASMをプロジェクトで活用する良いユースケースを見つけられていない。Raspberry Piをどう活用すればよいかわからないのと似た状況だ。Rustの非同期プロジェクトのためにWASMを選ぶ明確な理由が見当たらない。
  • Cross-Origin Isolatedヘッダーを必要としないソリューションがあればいいのにと思う。今でも古いバージョンを使っている。
  • WASMがElectronアプリの、よりリソース消費の少ない代替になり得るのか気になる。WASMにはDOMアクセスがないが、拡張機能で追加できるのだろうか。
  • このソリューションがどんな問題を解決するのかわからない。すべてのJavaScriptランタイムには、すでにWASMエンジンが組み込まれているのではないか。
  • このソリューションによって、Node.jsコードをサンドボックス内で安全に評価できるようになるのか気になる。
  • パフォーマンスグラフが読みづらい。千区切り記号としてカンマとピリオドが混在しており、精度も任意に1桁、2桁、3桁へ丸められている。