11 ポイント 投稿者 GN⁺ 2025-05-10 | 2件のコメント | WhatsAppで共有
  • Wasm 2.0 仕様が正式に発表
  • Wasm Community と Working Groups が 2022年から仕様を完成させており、主要な実装はすでに 2.0 をサポートしていた
  • 2.0 からは エバーグリーンモデル が導入され、Candidate Recommendation 文書が継続的に最新状態へ更新される
  • 新しいバージョンが発表されるたびに最終勧告へ移行するのではなく、現在の勧告案が標準とみなされる

Wasm 2.0 の主な機能と追加事項

  • ベクトル命令(SIMD): 236 個の新しい命令が追加され、現代的な CPU の 128ビット SIMD 機能を活用可能。高性能なオーディオ/ビデオコーデック、機械学習、暗号化などで効率的
  • バルクメモリ命令: メモリとテーブルの高速なコピーおよび初期化を可能にする命令セットが追加
  • マルチバリュー返却: 関数とブロックから複数の値を返せるようになり、呼び出し規約が改善され、追加のプログラム変換が可能に
  • 参照型: 関数への参照や外部オブジェクト(例: JavaScript の値)ポインタを不透明な第一級の値としてサポート。テーブルをこれらの参照値の格納先として利用でき、テーブルを扱う命令や複数テーブルの定義も可能に
  • 非トラップ変換: 浮動小数点から整数への変換時に予期しないトラップが発生しない変換命令を導入
  • 符号拡張命令: 符号付き整数の幅を直接拡張する命令が追加され、従来よりもメモリアクセスなしで拡張可能に

下位互換性と今後の見通し

  • Wasm 2.0 は 1.0 と完全互換 で、既存のプログラムがそのまま動作
  • Wasm 3.0 のリリースもまもなく予定されている

2件のコメント

 
caniel 2025-05-10

WA!(SM)

 
GN⁺ 2025-05-10
Hacker News のコメント
  • 2025年3月の Wasm 2.0 発表のニュースを要約すると、128ビット SIMD など236個の新しいベクトル命令によって動画・音声コーデック、機械学習、暗号化アプリケーションの性能が大きく向上し、バルクメモリ命令で高速なメモリコピー/初期化をサポートし、関数が多値を返せるようになったことで高速な呼び出し規約と間接参照の削減を支援し、参照型によって外部オブジェクト(JavaScript の値など)へのポインタを第一級の値として扱え、複数型のテーブル宣言が可能になり、ビット幅拡張命令や予期しないトラップのない浮動小数点変換も追加されるなど、大幅なアップグレードとなっている
    • Rust+LLVM は ABI 互換性の問題により、多値返却サポートを実際にはまだ活用できていない。Clang 側の状況はよく分からない
    • ベクトル命令(SIMD)の部分は、最適化を早く追い求めすぎて複雑になってしまったように思う。単に 可変長ベクトル提案を使っていれば、もっとエレガントだったはずだ
    • 多値返却機能は Common Lisp ランタイムの開発にも非常に 有益だろう
    • 公式ポストの最後に「まもなく Wasm 3.0 を紹介予定」と書かれているので、本当に Wasm 3.0 がそう遠くないうちに登場しそうだ
    • アーキテクチャ非依存で汎用的な ISA と、特定 CPU の SIMD を最大限活用する ISA は両立しない。どちらか一方を選ぶ必要がある。現在の Wasm2 SIMD 命令が十分に汎用的かどうかは、GitHub の rate limit のせいで確認できていない
  • WebAssembly の仕様はかなり読みやすい。ただ、仕様全文を見たくない入門者には WebAssembly from the Ground Up というオンライン書籍を勧めたい。JavaScript でコンパイラを自作しながら段階的に学ぶ構成で、実践に向いている。無料サンプルもある。ちなみに私は著者の一人だ
    • 個人的に Ada が好きな理由は、JavaScript のような煩雑な U32 チェック関数コードを、Ada では サブタイプ(subtype)やモジュールでとてもきれいに処理できるからだ
    • WASM コードをインストルメントして インプロセスデバッグ が可能なのか気になる。つまり、カスタム言語をリアルタイムで WASM に変換し、Web 上でブレークポイントやメモリインスペクションまで一括で実装できるのだろうか、という疑問だ
  • この1年ほど WebAssembly ランタイムの開発をしていて、仕様の厳密さ と充実したテストに感銘を受けた。慣れるまで少し時間はかかるが、一度慣れるととても賢い言語仕様だ。曖昧な状況では、仕様から直接生成されたリファレンスインタプリタが大いに役立ち、一貫性検証のための仕様テストも非常に有益だ
  • 最近 Wasm Constant Time 提案が inactive に移された。実際の作業の大半は2018年に行われたが、SIMD との連携や公式拡張への統合は先送りになっている。誰かがこの非常に重要な作業を引き継がない限り、すべての Wasm 暗号化は タイミング攻撃 に非常に脆弱な状況だ
  • Wasm は WebAssembly の短縮形であり頭字語ではないので、大文字の WASM とは書かないという点が印象的だ
    • その理屈なら WAsm が正しいのではないかと思う
    • 実際、頭字語であってもすべて小文字(例: scuba, radar, laser)で書かれる例は多い
    • うまくいくといいね(笑)
  • 実際に 動いている WASM アプリ の一覧が気になる。アイデアは良いが、DAPPs のように「面白いだけのもの」という感じがある。実例があれば知りたい
    • madewithwebassembly.com と Awesome-WebAssembly-Applications の GitHub を勧める。実際の WASM アプリがよく整理されている資料だ
  • 今回の WASM2 リリースは素晴らしいが、固定幅 SIMD(128ビット)の導入には惜しい点もある。ARM SVE のように、コンパイラがデバイスごとの性能に応じて SIMD 幅を調整する柔軟な方式の方がよかったはずだ
    • しかし私はむしろ固定幅 SIMD の方が、より多くの用途を開くと思う。ベクトル命令は固定幅 SIMD でも比較的容易に代替できる。SIMD が必須というわけではないが、レジスタサイズのおかげでベクトル化される 日和見的(opportunistic) な用途も多い。そういう場合にはかなり有用だ
    • 最適化を早くやりすぎることが問題の根本だ。この SIMD 問題も、いっそ 可変長ベクトル提案 だけに従っていれば、はるかにエレガントだったはずだ
  • C 関数が値を struct として返すとき、WASM にコンパイルされるのか気になる
    • 可能ではあるが、現時点では JS への「エクスポート(export)」はできないと理解している
  • WASM2 の機能をすでに実装しているランタイムがあるのか気になる
    • 大半はかなり前から実装してきている。Wasm コミュニティとワーキンググループは2022年初頭に仕様を確定しており、主要な実装はそれ以前から 2.0 を提供していた。3.0 もまもなく正式化される予定で、機能の一部はすでに feature flag 経由の状態だ
  • Web 向けバイトコードは昔からの夢だと思う。C# 開発者として、Blazor が初期から WASM を大胆に 先導してきた点が印象深い。.NET は WASM 上でかなり先を進んでおり、今回の 2.0 の変化にも期待している