- 聞き手：近藤佑子（編集部）、矢倉眞隆氏
- 協力：清水智公氏（Mozilla Japan）、浅井智也氏（同）
ルーク・ワグナー（Luke Wagner）氏
- WebAssemblyに関するディスカッション情報「Discussion: WebAssembly」
- ルーク・ワグナー氏のブログ
パフォーマンス向上の他、JavaScriptでできない機能を実現するWebAssembly
――ルークさんがMozillaで取り組んでいることについて教えて下さい。
ここ3～4年は、MozillaでJavaScriptエンジンやasm.jsの開発を行ってきました。ここ1年は、WebAssemblyのFirefoxへの実装や、仕様策定などに携わっています。
――まずasm.jsの概要についてご説明いただけますでしょうか。
asm.jsはJavaScript言語仕様のサブセットです。CやC++で書かれたコードをJavaScriptに変換し、ブラウザで動かせるようにするために開発が始まりました。
CやC++で書かれたたくさんのプロダクトがありますが、それをJavaScriptに書き換えるのは現実的ではないため、それを自動的に変換するものです。安全性や最適化を考慮したうえで高速に実行できるように変換しています。
全てのブラウザでサポートされており、数年の使用実績があります。ブラウザ上で動くゲームなどによく使われています。
――例えばどのようなゲームがありますか？
一番有名なのはUnityで開発したアプリケーションです。プラットフォームとして、AndroidやiOSの他、Webも対応しています。Unityは色々なゲームで使われていて、Web上のゲームだと、例えばFacebookのゲームによく使われています。
Unityで作られたゲームをブラウザで動かすには、Unity Web Playerというプラグインが必要でしたが、Unityは、今後そのプラグインを非推奨にし、WebGLへの出力を推奨すると発表しました。asm.jsは、UnityのコードをWebGLで動作させるために使われています。
Webへのビルドの際には、Emscriptenというコンパイラを使い、Unityで書かれたコードをasm.jsに変換することで、WebGLで動作できるようにしています。
――ではなぜ、asm.jsがあるにも関わらず、新しくWebAssemblyが開発されているのでしょうか。
asm.jsによってパフォーマンスを出すことが可能になりましたが、一方で、違う制約があることに気づきました。それはロード時間です。
コールドロードといって、JavaScriptを実行するまでの、パージング（ブラウザが構文を解析して実行可能な形に変える工程）にかかる時間がとても大きいです。特にモバイルデバイスでは、Unityから出力した40MBのJavaScriptのコードを読もうとすると、実行まで2～30秒の時間がかかります。この課題を解決するためにWebAssemblyが必要とされています。
WebAssemblyの開発のモチベーションとなっているのは、ロード時間のほか、JavaScriptの処理系ではできない機能を実現することもあります。
例えば、ダイナミックリンクやスタックウォークの実現です。スタックウォークができると実行が早くなったり、スタックの戻るアドレスを変える、処理の継続する先を変えるなど面白いことが色々とできたりします。
次にヒープサイズの制限を緩和すること。JavaScriptだと4GBしか使えず、小さいので、それをもう少し広く使いたいという目的もあります。
さらに、メモリに対するデータの書き込み、読み込みの操作の意味をもっと変えられるようにしたい。特に長い配列のデータがあったときに、アクセスされたときのインデックスが、配列の全体のサイズより内側にないとセキュリティ的に問題になります。64ビットの配列だと内側にあるかどうかハードウェアが指摘してくれますがが、32ビットだと確認しなければならない。WebAssemblyを使うと、確認をしやすいコードに変換してくれます。
――WebAssemblyのコードと普通のJavaScriptは、同じようにメモリ管理されているのでしょうか。
ブラウザで、JavaScriptがタブごとにメモリを分けて管理しているのと同じように、WebAssemblyと普通のJavaScriptを完全に分けてメモリ管理をしています。オプションで共有することもできますが、デフォルトだとパフォーマンスと安全性を優先し、専用の領域を作っています。エンジンが2つあるようなイメージです。
――asm.jsやWebAssemblyと、ネイティブとの違いを教えて下さい。
asm.jsやWebAssemblyは、まだまだパフォーマンスが遅いですね。asm.jsだとネイティブの1.5倍増しの時間が必要ですが、それがWebAssemblyだと1.1～1.2倍程度になっています。WebAssemblyは、asm.jsにある制約を取っ払い、少しずつネイティブのスピードに近づくような仕組みが入れられているため、高速化が実現されています。今後コンパイラの進歩や、JavaScriptのランタイムでの最適化などの試行錯誤を通じて、オーバーヘッドは小さくなっていくだろうと思います。
Microsoft、Google、Apple……みなWebAssemblyに注目している
――このWebAssemblyはゲーム以外にどのようなことに活用できそうでしょうか。
ゲームをよく提示しているのは、強力な活用例だからです。ゲームができれば他の用途のアプリケーションもできる。Cのコードをつかう領域、例えば科学データや医療データの可視化、CADなどは典型的です。
――asm.jsやWebAssemblyが一般的になったときに、今後活躍するのはフロントエンドとC／C++、どちらのエンジニアでしょうか。
フロントエンドエンジニアの仕事がなくなるわけではなく、フロント部分を実装する言語はJavaScriptであり続けるでしょう。asm.jsやWebAssemblyが使われる領域は強力な計算機資源を必要とし、重たい仕事をさせるのに向いているもので、必要となるのはそう多くはありません。それらはライブラリという形で提供されるので、C／C++のエンジニアはこのライブラリの開発で活躍するでしょう。
――WebAssemblyが発表されて間もないうちから、AppleがWebAssemblyのサポートを実験的に追加し始めたのは、今までのAppleからするとちょっと異質に思えました。各ブラウザベンダのWebAssemblyに対するスタンスはいかがでしょうか。
Appleは、WebAssemblyに対して、それが本当に動くのか、きちんとニーズを満たしているのかを確かめるために、実装してみたのではないかと思います。asm.jsを使うサードパーティが増えてきて、リアルなユースが彼らの目にも明らかだから、そういう動きをとったのではと考えています。
Googleは、自分たちのエンジンにasm.jsを組み込む際のサブセット化に苦心していたようでした。WebAssemblyだと簡単にいきそうだということで開発のモチベーションが上がっているようです。
マイクロソフトは、WebAssemblyが進化的、前進的な仕組みだいってすごく気に入ってくれました。それが、新ブラウザEdgeのasm.jsのサポートにつながっているのだと思います。
――ありがとうございました。
