見出し画像

WebAssembly Summit まとめ(後編)

WebAssembly Summit というカンファレンスへ参加してきました。午後にあったセッションのまとめです。午前のまとめはこちらへどうぞ

TD;DR; 午後は応用事例について扱いました。Web アプリケーションでの事例と Web 外での事例が 2 件ずつ紹介され、最後に WebAssembly のパイの拡大する様子を振り返りました。よくあるカンファレンスらしい内容だったように思います。

WebAssembly Music

オーディオプログラミングの経験が長いスピーカーによる、ライブコーディング環境のデモと紹介でした。この Web アプリでは、SonicPi のように、パターンや音源をコードとして表現することで、音を使ったライブパフォーマンスができます。

画像1

・音の再生パターンを AssemblyScript(?) として表現できる。
・音色をコントロールは AssemblyScript で表現できる。
・コードはブラウザ上でコンパイルされて実行される。
・実行には AudioWorklet を利用
・曲は Wasmer で実行可能な WASM ファイルとして出力可能

AssemblyScript コンパイラは、ざっくり言うと TypeScript の構文解析器Binaryen とを組み合わせて作られています。そして Binaryen には JS ビルドが存在ます。このおかげで、AssemblyScript コンパイラはブラウザ上で動作させられます。

Making it easier to make Things: WebAssembly and the Internet of Things

スピーカーはサンフランシスコの WASM ミートアップである WASM SF のオーガナイザー。午前は席がたまたま隣になって、6$ くらいの WiFi + BT ののってるボードで WASM による L チカを見せてもらいました。6$ か…

・WASM はポータブルで、セキュリティが最初から考慮されている
WASM-miscro-runtime Unikraft でビルド、RaspberyPi で動かすデモ
Wasm3 を Arduinoに入れて L チカを動かすデモ
・MQTTやCoAPの実装の多くは C。WASM/WASIの出番
dfu-utilでファームウェアはアップデートできる
OpenOCDは使えるデバッガ
Linodeが提供する IoT エミュレータ
WebUSB にも期待。

WASM Runtime を Unikernel / LibraryOS とリンクして使う手法は夢があると思いました。

Building a Containerless Future with WebAssembly

サーバサイドの経験が長いスピーカーによる WASM VM / コンテナーの紹介でした。WASM ランタイムの上に抽象度の高い実行環境を実装することで、開発者はビジネスロジックに注力できる、という趣旨の講演でした。

・WASMはクラウド環境でも、色々優位点がある
・e.g. サイズ、サンドボックス、メモリアイソレーション、ポータビリティ
・簡単にディスアセンブルできる点も良い
・WASMランタイムの上に抽象度の高いランタイムが作れる
・e.g. waPCwascapwaSCC
・ランタイムで、ビジネスロジックと環境とを切り離せる
・e.g. データをどこに、どうしまうかとかは、ランタイムの中に隠蔽できる
・隠蔽によって、ビジネスロジックとインフラとを独立に変更できる

マイクロサービスだと、個々のコンテナには抽象度の高い、少量のシステムコールがあればいいんだろうなあ、などと考えた気がします。そういえば IoT の話でも、少量のシステムコールをライブラリを使って提供してましたね。興味深い。

WebAssembly as a <video> polyfill

Wikimedia 財団のリードエンジニアによる、WikiPedia 向けに video 要素のポリフィルを作った話でした。

・Wikipediaは動画や音声メディアもサポートしているがコーデックが問題
・デファクトスタンダードのビデオコーデックはなかなか出てこない
・asm.js 版を WASM にしたら、パフォーマンスがよくなった
・次はマルチスレッド化。有効にするために、COOP / COEP の設定もした
・ハイパースレッディングを許可しないOSもある
・そんな場合はコアを使い切れない
・128bit SIMD は、多くのアーキテクチャでサポートされてる
・畳込みをしてる部分を例に、SIMD を使って書き換えた
・AV1デコーダーの asm.js 版 on IE11とWASM 版 on Chrome を比較
・asm.js の方はJITが終わるまでカクカクしてる
・一方 WASM 版は最初からなめらか

post MVP の仕様の実装が進むと、WASM でも feature detection が必要ですす

Thread は使えるか?」
「SIMDは?」
多値関数を使ってるけど、大丈夫なのか?」

このようなことをまず調査してから、実行環境に合わせた関数を実行することが必要となるしょう。

これを実現する仕様として Conditional Section も提案されています。ただ、まだ議論が必要です。現在の最適解は、そして将来のフォールバックとしては JS で対応する機能を調べて、結果に合わせた WASM ファイルをロードするということになると考えています。

複数種類のビルドを作る、というのは手間ですよね。テストのパターンや、フォールバックの設計と実装、などなど考えることは増えます。

まず MVP だけでできることを考えて、それをベースラインとして実装し、ベースラインを最適化、高速化する手段として post MVP の機能を使うということで、バリエーションの数を抑えることはできるかもしれません。

それでも 1 つのイメージをビルドすればおしまい、とならないのは悩ましい限りです。よしなにしてくれるツールが欲しい。

WebAssembly: Expanding the PIE

W3C WASM CG のチェアによるクロージングセッション。2015 年からの歴史を 1 年ごとに振り返りながら、WebAssembly の仕様が拡充していく様子を見ていくセッションでした。

・やると決めてから2週間でプロトタイプ作った
・2週間で終わると思ったが、結果 5 年もやっている
・2017年の時点で、GC は作ろうと思ったら作れた
・全ての変数が線形メモリ上にあるなら
・仕様上ローカル変数はスタックの上にあることが大切だった
・Embedder 側からの参照の解決も決まってなかった
・2018年の時点で 参照や構造体を表す型が導入された
・参照は、Embedder 側の物も指せるのでなかなか大変
C APIも2018年に提案された
・2020年。参照型は Phase4 になりそう

最初から先頭を走っている人らしいセッションでした。プロトタイプとして作ったV8 のバイトコードが、そのまま WASM のバイトコードの仕様になった、みたいな話はこういう人じゃないとできないでしょう。

彼が使っていた APIE の 4 カテゴリは、仕様の分類としてとても便利なので、今後使っていこうと思います。

A(Ability):WASM のできることを定義する仕様
P(Producer):コンパイラにむけた仕様
I(Interoperability):他の環境との、相互運用を可能にするための仕様
E(Embedder):WASM モジュールを呼び出す側の仕様

画像2

まとめ:WASM の成果を確認する午後

午後は WASM の利用事例に関するセッションがまとめられていました。いろいろ工夫して、楽しみつつ、やってるなあ、という印象でした。

WikiPedia の video ポリフィルは典型的な利用例で、Web 開発者としては学びは多いように感じました。Progressive Enhancement という考えが WASM にもやってくるというのは、悩ましくもあり、Web らしさが出てきたとも言えると思うので楽しみです。

non-Web の利用例の話は、UNIX システムコールを全て用意しなくてもいい、という点に気づけたのが良かった。マイクロカーネルというのは、そういう話でしたね、というか。

心残りは、ポータビリティとセキュリティを担保しつつ、デバイスへの I/O をどのように提供していくかという点について話を聞けなかったことです。

線形メモリの 1 部分をつかって DMA とするアプローチや、/dev を定義して WASI の提供する open / read / write / close を使ってアクセスする方法、HAL を定義して関数呼び出し経由でアクセスする方法、などなどあるとは思います。どれが有力なのか、それとも他に考えはあるのか、という話を誰かにきければ良かったなと思っています。

「来年も開きたい。できれば 2日間。」

と主催者はおっしゃっていたので、ぜひ来年開かれることを楽しみにしています。


この記事が気に入ったらサポートをしてみませんか?