2022/02/22 に Geologic Conference で発表した内容です

1. WebAssembly
in Action
2022/02/22
Takuo Kihira

2. 自己紹介
紀平 拓男（きひら たくお）
スマートニュース株式会社
● 20 年くらい JavaScript の世界で働いています
● サンフランシスコでの起業を含め 3 社の起業を
経験しています
● 最近はネイティブアプリ内に組み込む Web の
開発に興味を持っています
星の軌跡の撮影本を出版しました。見てね！
https://www.amazon.co.jp/dp/4297126036/

3. 世間一般の WebAssembly のイメージ
● 速い！
● 小さい！
● 色々な言語がブラウザで動く！

4. 現実
● 速い！ → 遅くはない
● 小さい！ → そんなに小さくない
● 色々な言語がブラウザで動く！ → C/C++/Rust は比較的簡単に動く

5. WebAssembly とは
https://ja.wikipedia.org/wiki/WebAssembly
● WebAssemblyは仮想命令セットアーキテクチャあるいはプログラミング言語の一種である[2]。略
称はWasm[3]。C・Rustなど様々なプログラミング言語のコンパイルターゲットとしてWasmバイ
ナリは生成され、ウェブブラウザを含む様々な環境内のスタックベース仮想マシンにより実行され
る。
ネイティブコード相当の高速性・隔離環境でのメモリ安全な実行による安全性・仮想マシンによる
ハードウェア/プラットフォーム可搬性・ソースプログラミング言語中立性などを特徴とする[4]。
この命令セットはバイナリ形式で定義されており、またアセンブリ言語ライクなテキスト形式も定
義されている（その意味で低水準プログラミング言語といえる）。
Wasm自体は命令セットアーキテクチャであり、Linuxカーネルが提供するようなシステムコール（
例: ファイルI/O）、Webブラウザが提供するようなDOMアクセスなどを提供していない[5]。

6. WebAssembly の特徴
● 速い！ → 遅くはない
○ 高速性
○ 安全性
○ 可搬性
● 小さい！ → そんなに小さくない
○ バイナリ形式で定義
○ Linuxカーネルが提供するようなシステムコール（例: ファイルI/O）、Webブラウザが提供す
るようなDOMアクセスなどを提供していない
● 色々な言語がブラウザで動く！ → C/C++/Rust は比較的簡単に動く
○ プログラミング言語のコンパイルターゲットとしてWasmバイナリは生成
○ 言語中立性

7. 速度
● 速い！ → 遅くはない
○ 高速性
○ 安全性
○ 可搬性

8. WebAssembly はなぜ高速か
● JavaScript はスクリプト言語であり、動的言語であるため、速度が遅い
○ スクリプト言語であるため、構造が複雑である
○ 動的言語であるためコンパイルすることが出来ず、実行速度が遅い
● WebAssembly はツリー構造のバイナリで、構造は型付きS式
○ バイナリはブラウザ内部のVM（スタックマシン）で実行されることを想定した形式
○ 実際は wasm を再度コンパイルし、ネイティブコードに変換してから実行される
● wasm は構造がシンプルであり、ネイティブコードにコンパイルしやすい
○ 高速になる条件は完全に満たしている

9. WebAssembly はなぜ思ったほど速くないのか
● JavaScript が速い
○ ブラウザの JavaScript エンジンは大企業から猛烈な投資を受けて成長している
○ JIT が優秀で下手なコンパイル言語並にものすごく速い
● WebAssembly は安全性の確保が大事
○ 悪意のあるコードが来ても問題ないようにサンドボックス内部で実行される
○ メモリアクセスのたびに境界を超えていないかチェックが必要、これが結構重い
● ポータビリティ担保の必要からネイティブコードを送れない
○ ガチでコンパイルしたネイティブコードとブラウザ上で急いでコンパイルするコードだと
最適化できる範囲が全然違い、実行速度に差が出る

10. WebAssembly の速度の大きな欠点
● 起動がとてつもなく遅い
○ Wasm のバイナリをネイティブコードにコンパイルする処理がリロード時に毎回必要
○ コンパイルした結果をローカルに保存できる仕様が削除された
● 初回訪問時は大きな問題にならない
○ ファイルのダウンロード速度とコンパイル速度だと、コンパイル速度の方が速い
○ ストリーミングコンパイル出来るので、ダウンロードしながら同時にコンパイルも出来る
○ しかし、wasm ファイル自体はキャッシュ出来るが、コンパイル結果はキャッシュ出来ない
● 具体的なコンパイル速度
○ http://nmi.jp/2017-12-03-Profiling-of-huge-wasm 2017年末のデータ
○ 25MB の wasm はゲームでは普通だが、20秒から下手すると1分くらいかかる

11. サイズ
● 小さい！ → そんなに小さくない
○ バイナリ形式で定義
○ Linuxカーネルが提供するようなシステムコール（例: ファイルI/O）、
Webブラウザが提供するようなDOMアクセスなどを提供していない

12. WebAssembly で必要なファイル
● Wasm 本体
○ バイナリ、とても小さい
● Wasm と JavaScript が通信するコード（グルーコード）
○ JavaScript、結構でかい
● Wasm でC言語の標準ライブラリなどをサポートするランタイムコード
○ バイナリとJavaScript、相当でかい

13. WebAssembly でサイズを減らすには
● Wasm 用の言語で書く
○ 例: AssemblyScript とても小さいファイルを出力できる
● ランタイムを利用せずに書く
○ 例: fdlibm C言語だが malloc すら必要がなかったので相当小さなファイルを出力できた
● ランタイムが小さな言語で書く
○ 例: Rust ランタイム小さいしグルーコードもかなり小さい

14. Emscripten のファイルサイズ
● Emscripten
○ 既存のC/C++の移植では普通これを使う
○ 標準ライブラリのみならず、mlib、OpenGL、pthread など様々な API に対応している
○ ランタイムがむちゃくちゃでかい
● LibRaw の wasm 移植 のデータ
○ 依存のないライブラリ、内部では標準ライブラリのみの使用
○ JavaScriptコード: 86KB
○ Wasm: 619KB

15. 言語
● 色々な言語がブラウザで動く！ → C/C++/Rust は比較的簡単に動く
○ プログラミング言語のコンパイルターゲットとしてWasmバイナリは生成
○ 言語中立性

16. WebAssembly の出力方法
● Clang / Rust / AssemblyScript
○ 直接コンパイラが wasm のコードを出力する
● EmScripten
○ LLVM の中間言語を通じて wasm のコードを出力する
EmScripten 方式だと、LLVM が対応している言語は理論上全て wasm 化可能

17. 言語を移植する上でのハードル
● ランタイム
○ 標準ライブラリ
○ 言語機能実装
● ガベージコレクション
○ Wasm は現在 GC をサポートしていない
○ GC に頼る言語は、自前で GC を実装する必要がある
○ ページ内に 2 つ wasm をロードすると、GC 実装が 2 つ必要になったりする

18. 動く言語
● C/C++
○ Emscripten の手厚いサポート
○ Clang から直接出力することも出来る
● Rust
○ コンパイル言語、軽い標準ライブラリ、ガベージコレクションなし
● Go
○ すっごく頑張っている
○ GC 自前実装、ランタイムも頑張ってる
○ ファイルサイズも速度もイマイチだが、動くということが重要

19. 現在の Wasm の使われ方

20. 移植か、高速か
● 既存の資産の移植
○ 例: LibRaw、ffmpeg、DOSBOX、ゲーム各種など
○ 枯れた技術をそのまま適用できる
○ 今まで JavaScript になかったライブラリなども利用可能に
● 実行時の速度がとてつもなく欲しい時
○ そんなに速くないといっても、JavaScript よりは同等か速いか、くらいにはなる
○ エンコーダーとか、ビデオに blur をかけるとか、速度が本気で重要な場合は wasm は良い

21. プロダクションに耐えうるか
● よく検討すべき
○ メンテナンスとか結構たいへん
○ Block Pong で Wasm のバグを踏んで泣いた話を Google Developer Group で発表した
■ https://docs.google.com/presentation/d/1OmFQahgOZvd5kqI-
P3oXaW5tn75IqId9lKKo1SVne30/edit
○ 他に選択肢がない場合は使っても良い、が、基本まだオススメしない
■ 相談してください

22. ご清聴ありがとうございました