WebAssembly Summitというカンファレンスへ参加してきました。その午前のセッションについてまとめました。午後のセッションについては別記事でまとめます。

TL;DR; 午前はWASMを取り巻く問題について扱ったように感じました。いくつかには解決策が提示され、いくつかは問題提起にとどまった印象です。

WebAssembly Summitとは？

Webブラウザの上で実行できる第2の言語、それがWebAssemblyです。誕生は2015年にW3Cのコミュニティグループが結成され、2019年末に正式な仕様としてリリースされました。このWebAssemblyのツールやランタイム、そしてWebAssemblyを使ったアプリケーションに関する発表を行うカンファレンスが、WebAssembly Summitです。

WebAssembly は、ネイティブのアプリケーションやエッジサーバにおける処理といった Webブラウザ外での実行を最初からスコープに入れて仕様が定められています。またWASIやBytecode AllianceなどのWebブラウザ外で利用に対する注目が高まっています。それを受けて、セッションの半分はWebブラウザ以外での利用例について扱っていました。

セッションは午前にキーノートを含めて4つ、午後には4つのセッションとクロージングのキーノートがありました。午前はツールやランタイムの話で、午後はアプリケーションの話でした。YouTubeにあるアーカイブでセッションの様子を見られます。

以下、それぞれのセッションについて内容と、感想を簡単に述べていきます。

WebAssembly : Building a new kind of ecosystem

全体のキーノートです。講演者は Lin Clark。Mozilla で WebAssembly 関係の記事を執筆や、標準化を行っている人です。ネイティブアプリケーションの文脈で WebAssembly と ByteCode Alliance の紹介をしていました：

・コードの8割は第3者が作ったもの
・計画的な攻撃が増えている中、セキュリティの重要性は高くなっている
・WASM はモジュールごとにサンドボックスが用意される
・WASM を使うことで、マイクロサービスアーキテクチャのように、
　ネイティブアプリを設計することができる

Shipping Tiny WebAssembly

Emscripten の作者がバイナリサイズを小さくするための手法の紹介していました。ツールの使い方やコードの書き方について掘り下げていましたが、ハイレベルにまとめると、以下の 3 点になるかと思います：

・使わないコードの削除（Dead Code Elimination; DCE）を行う
・Link Time Optimization (LTO) を行う
・JSに同等の関数があるなら、JSを直接呼ぶ

セッションで多く触れられていたのが、wasm-opt というオプティマイザーです。これはWASMバックエンドである binaryen に含まれるツールで、最適化を行います。これを直接実行して最適化してもいいですが、最近のEmscripten  / wasm-bindgen / AssemblyScript は、このコマンドを内部で利用するようになっている、ということでした。-O オプションの設定を確認するところからはじめると良さそうです。

WASM 化した wasm-opt を使って WASM を最適化する wasm-shr.ink というサイトも紹介荒れていました。

Why the #wasmsummit Website isn't written in Wasm

エモいセッションでした。スピーカーは wasm-pack の作者の1人です。内容は右往左往、いろいろありました。

開発者が WebAssembly を使えるようになるために、ツールやプログラムに投資するべき

この主張はそのとおりだと思いました。ツールやライブラリによって隠蔽されて気づかないうちに使ってる、というのが理想的な形なのかもしれません。

JavaScriptCore's new WebAssembly interpreter

JavaScriptCore（JSC） とは Webkit が利用している JS / WASM ランタイムのことです。JSC に WASM インタプリタが導入された経緯について、開発者が説明していました。

・コンパイルと実行前処理に時間がかかることが問題だった
・その解決策として、インタプリタの導入を行った
・インタプリタで起動し、その裏でネイティブコードへのコンパイルを行う
・その後、関数本体をインタプリタからネイティブコードに差し替える
・ネイティブコードで実行しつつ、裏では最適化されたコードの生成を行う
・最適化コードができたら、それに差し替える
・様々な評価の結果、この3層が最も性能が高かった

午前：問題意識のまとめ

コアスペック が W3C で標準となり、Post MVP の仕様も議論と実装のステージが上がってきています。処理系は V8, SpiderMonkey, JSC といったブラウザ向けのものだけでなく、Wasmer や Lucet のようなブラウザ外での実行を意図したものも多く出現しています。そして徐々にではありますが採用事例も出てきている、というのが WASM の現状だと思います。

一方で、アプリの設計方法/方針に決め手がない（ように見える）ことや、使いやすいツールがないことから、開発者、特に Web 開発者からの支持を得られていないとも思います。

また JS と比較してバイナリサイズが大きくなりがちで、事前コンパイル（AOT)を想定した仕様でもあるため、 Web アプリのロードパフォーマンスに問題が出やすいことも知られています。V8ではキャッシュを工夫することで問題に対抗しようとしていますが、初回ロードに対する問題は配布するバイナリサイズと、ランタイムの実行前処理の性能によって決まる部分が大きいように思います。

設計方針、バイナリサイズの最適化、ツールチェーン、処理系。これらの点に対する問題意識を整理したのが午前のセッションだったように思います。

参加していた時は、応用事例を期待して参加していたため、拍子抜けした感もありました。しかし帰国して、折に触れて思い返してみると、なかなかに味わい深く、良い構成だったように思うようになってきました。

午後のセッションについては、別の記事でまとめます。

2020/02/28 追記：午後のセッションのまとめを作りました。