こんにちは、編集長の白石です。

この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に、様々なお話を伺おうというものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、WebAssemblyコミュニティを率いてらっしゃる清水 智公さん（@chikoski）です。清水さんのセッションは「WebAssembly MVPまとめと、今の議論の内容からいくつか」でした。

※スライド資料はこちらで公開されています。

WebAssemblyとは何か？

白石: 今日はよろしくお願いします。まずは自己紹介をお願いできますか？

清水: WebAssemblyのコミュニティを運営している清水です。@ikkoさんと一緒に、「emcscripten night !!」というイベントを四半期に一回くらいのペースで開催しています。

白石: では早速ですが、WebAssembly（WASM）とは何なんでしょうか？

清水: 一言で言うと、Webブラウザ上で実行できる、ポータブルなバイナリ形式です。現在、「MVP（Minimul Viable Product: 最小限有用な機能を備えたプロダクト）」の実装が完了し、ほぼすべてのメジャーブラウザで利用できるという状態です。

白石: ポータブルというと、ブラウザにも、OSにも、デバイスにも依存しないということですね。

清水: その通りです。Javaをご存じの方であれば、classファイル形式を思い浮かべていただくと理解は早いと思います。

白石: なるほど。なぜそうしたバイナリ形式が必要とされたんでしょうか？

清水: これまでWebページで動作するプログラミング言語といえば当然JavaScriptだったわけですが、JavaScriptは遅いという問題がありました。asm.jsでスピードの面は大分改善されたのですが、今度はサイズが大きくなってしまうという問題も生まれました。それで早く動かせて、サイズもasm.jsよりは小さいものとして、WebAssemblyが生まれたんです。

遅さの原因の一つは、JavaScriptは変数の型が動的だということです。例えばJavaScriptで足し算を行うコードがあるとしたら、いろんな可能性を考慮しなくちゃいけないんですよね。

値が整数かもしれないし、浮動小数点かもしれない。文字列かもしれないし、valueOf()を持つオブジェクトかもしれない。こういう可能性を踏まえると、単なる足し算といえども最適化は容易じゃないわけです。

ですがWebAssemblyの場合は、コンパイル時に変数の型が決まるので、最適化が容易なんです。今では、ネイティブに比べて2/3くらいの速度というところまで改善されています。

白石: なるほど。サイズが小さくなるという点についてはいかがでしょう。

清水: JavaScriptは当然テキスト形式ですが、テキストってやはり冗長なんですよね。例えば、とあるゲームのコードを全部JavaScriptに変換したところ、40メガバイトを超えるサイズになってしまったことがあります。

これでは、JavaScriptのソースコードをダウンロードするだけでかなりの時間がかかってしまうし、実行にかかるコストも半端ではありません。

WebAssemblyは、サイズを小さくすることを最初から念頭に置いたバイナリ形式ですので、確実にサイズは縮まります。元のJavaScriptファイルにもよりますが、ミニファイして圧縮した場合に比べても小さくなるのは確実。場合によっては半分以下のサイズになることもあります。

白石: それほど素晴らしいのであれば、将来的にはJavaScriptを置き換えていくような存在になるのでしょうか？

清水: いえ、WASMはJavaScriptの置き換えは目指しておらず、あくまで補完する存在という位置付けです。例えば、WASMはDOMに直接アクセスすることができませんからね。

WASMへの対応状況

白石: では改めて、ブラウザのWASMへの対応状況を教えていただけますか？

清水: 先ほども申し上げたとおり、ほとんどのメジャーブラウザで使えます（参考: Can I Use）。Safariが11から対応するようになったのは大きいですね。iOSでも使えるようになったということなので。 Edgeも先日のCreator’s updateでデフォルトでWebAssemblyを利用できるようになりました。また、Node.jsでもWebAssemblyは動作します。

白石: Nodeでも動くんですか！知りませんでした。WASMにコンパイル可能な言語には、どのようなものがありますか？

清水: 様々なコンパイラで利用されている、LLVMという中間言語があるんですが、LLVMに変換される言語だったらだいたい大丈夫です。Emscriptenというツールを使うと、LLVMからWASMに変換できるのです。

LLVMにコンパイルできる言語というと、C/C++/Objective-Cなどが挙げられます。また、RustもWebAssemblyに対応しています。

あとUnity限定になってしまうのですが、C#にも対応しています。他にはAssemblyScriptといって、WebAssemblyを出力できるTypeScriptのサブセット言語も存在します。

白石: C#やTypeScriptもあるんですね！WebAssemblyにはガベージコレクタがないと聞いていたので、それらの言語が使えるというのは驚きです。

ちなみに、WASMを出力できる言語や動作する環境がたくさんあるのはわかったのですが、実際どれくらい実用的なんでしょうか？

清水: 今は、ざっくり言ってC言語のコードをコンパイルして動かす能力は備えているというところです。 C++への対応は完全じゃありません。C++の例外をまだうまく扱えないんですよね。

白石: Cと言えば、メモリを直接操作するようなコードを直接書けると思うのですが、それがWebAssembly上だとどのように動作するのでしょうか？

清水: WebAssemblyのコードには専用のメモリ空間が割り当てられるんです。C言語におけるメモリ操作などは、そのメモリ空間に対して行われます。そのメモリ空間は、JavaScriptコードからもArrayBufferオブジェクトとして参照できます。

ちなみに、WebAssemblyの仕様上は64ビットのメモリ空間を扱えるのですが、現在の実装上では32ビットに制限されていますね。

WASMを使う

白石: WASMを使うコードはどういうふうになりますか？

清水: まず、WASMのバイナリが必要です。拡張子は.wasmです。そのファイルをfetch()でもXMLHttpRequestでも何でもいいので読み込んで、バイナリコードをArrayBuffer化し、WebAssembly.instanciate()というメソッドに渡します。

すると、WebAssemblyコードの実行結果がPromiseの戻り値として返ってくるので、そこにエクスポートされている関数をJavaScript側から呼び出すことが可能です。

// MDNのサンプルを引用
// https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/instantiate

// WASMファイルを読み込み
fetch('sample.wasm').then(response =>
  // ArrayBuffer化
  response.arrayBuffer()
).then(bytes =>
  // インスタンスを生成
  WebAssembly.instantiate(bytes)
).then(result =>
  // 生成されたインスタンスのエキスポートされた関数を呼び出し
  result.instance.exports.exported_func()
);

白石: なるほど、使うのはそれほど難しくなさそうですね。JavaScriptからシームレスに関数の呼び出しを行えるのが素晴らしい。

清水: はい、それにWASMのコード内から、外部JavaScriptのコードを呼び出すことも簡単にできます。WebAssembly.instantiate()の第二引数で、WASMコードがインポートするメンバーを指定できるんです。

// MDNのサンプルを引用
// https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/instantiate

// WASMがインポートして使用するオブジェクト
var importObject = {
  imports: {
    imported_func: function(arg) {
      console.log(arg);
    }
  }
};
fetch('simple.wasm').then(response =>
  response.arrayBuffer()
).then(bytes =>
  // インポートするオブジェクトを指定
  WebAssembly.instantiate(bytes, importObject)
).then(result =>
  result.instance.exports.exported_func()
);

白石: なるほど、ダイナミックリンクが可能なんですね。WASMがJavaScriptをどう補完するのか、よくわかりました。

WASMはどう使われていくか

白石: WASMが登場したことで、具体的に何が変わっていくと思いますか？

清水: まずはやはり、C/C++で書かれたコードをWASMに変換して使うのが一番最初に思いつくユースケースです。 コンシューマー向けのサービスでいうと、やはりゲーム系がすぐに思いつきますね。

例えば新たなゲームタイトルをスマホ向けにネイティブで開発しつつ、WASMでコンパイルしてWeb版も同時に開発するということができます。 UnityはWebAssemblyに対応しているので、そういう開発を行うのは比較的簡単です。

白石: なるほど、スマホ版だけじゃなくてWeb版も同時に開発して公開できれば、ユーザーへのリーチが拡大しそうですね。

清水: 実際、とあるベンダーさんが、Android用のゲームをWebブラウザでも動作するようにしたところ、ユーザー数はかなり増えたと聞いています。

白石: では、まずはネイティブとWebのクロスプラットフォーム開発でWASMは活躍しそうだと。 他にはC言語で書かれた資産とかもWeb上で使えそうですよね。例えばgzipのライブラリとか。

清水: そう、圧縮や暗号系、画像処理などの、Cで書かれたライブラリをWeb上に移植するのにも向いていますね。 CPUに依存する処理を高速化するのには、すごく向いています。

Cで書かれたコードの移植といえば、luaもWASMにコンパイルできたそうです。

白石: おお、言語処理系まで！そうか、よく考えたら、現在のWASMにガベージコレクタがなくとも、ガベージコレクタを備えた処理系ごとコンパイルしちゃえばいいんですね。

WASMのこれから

清水: はい、ちょうどガベージコレクタの話が出たので、WASMのこれからという話をしたいと思います。WASMの次のターゲットとして、ガベージコレクタが提案されています。

こちらはおそらく、「ガベージコレクタを使いたい場合は使える」という設計になると予想されています。

白石: ガベージコレクタが使えるようになったら、WASMをターゲットにした言語処理系とかが作りやすくなりそうですね。WASMで提案されている仕様は他にもありますか？

清水: まず、スレッドを使えるようにするという提案があります。 やはり、pthread (POSIXスレッド: C言語で使用できるマルチスレッドAPI)を使いたいという要望が多いんですね。 複数のWeb Workers（Web環境でマルチスレッディングが可能なAPI）で共有できる Shared ArrayBuffer は既に利用可能ですが、複数のスレッドを待ち合わせるwaitやwakeと言った命令も使えるようにすることを見据えています。

他には、先ほども申し上げたように例外を扱えるようにして、C++コードもWASMに正しくコンパイルできるようにすること。WASMのモジュールとECMA Scriptモジュールの整合性を取る…と言った提案も行われています。

白石: WASMの未来、楽しみですねー。最後にお聞きしたいのですが、現時点でWASMを試すのにおすすめの言語はありますか？C/C++で書くのはなかなかしんどいなあ、と…

清水: HTML5 Experts.jpの読者に向けてという話であれば、TypeScript（のサブセット）をWASMにコンパイルできる、AssemblyScriptを使うのはおすすめです。Web技術者が軽く試してみるという用途には最適だと思います。

白石: 本日は、WebAssemblyについて基礎から最新情報まで教えていただき、ありがとうございました。

低水準言語asm.jsとWebAssembly詳解の第4回目です。前回までで、asm.jsの必要とされる理由と、その仕様、そしてasm.jsを生成するツールであるEmscriptenを紹介しました。CやC++で書かれたソースコードから「低水準」なJavaScriptコードが出力され、それが高速に動作する理由について述べてきました。

前回の最後で述べた通り、Emscriptenで出力されたasm.jsのファイルはサイズが大きくなりがちでした。ファイルのサイズが大きくなるとダウンロードに時間がかかるのはもちろん、ネイティブコードへのコンパイルにも大きく時間がかかってしまいます。つまり高速に動作するのは良いが、起動に時間がかかるサイトができてしまうことになります。

この問題を解決するために登場するのがWebAssembly(WASM)です。これはプログラミング言語ではなく、ファイルフォーマットの一種です。 同じプログラムをasm.jsとして出力したものと、WASMとして出力したものを比較すると、WASMの方がぐっと小さくなっていることがわかります。

現在はその仕様策定が固まり、ブラウザへの実装も済み、リリースを待つばかりです。またコンパイラへの実装も進んでいます。特にBinaryen（後述します）への最適化処理の実装のおかげで、asm.jsより高速に実行できるようになりました。

下記のグラフ（MozillaのHacksブログより引用）はasm.jsとWASMの速度を比較したものです。値はネイティブの実行スピードに対する相対的な速度を表していて、1に近づけは近づくほどネイティブに近いスピードで動いていることを表しています。Bulletを除く全てのベンチマークでasm.jsより高速に動いています。これはコンパイラの行う最適化処理のおかげです。

この評価は2016年10月末の時点に、Intel Core i7-2600 @ 3.40GHzで動作するLinux版 64-bit Firefox 52 (Nightly)で計測されました。現在は最適化処理の更なる修正によって、Bulletでもasm.jsを上回るパフォーマンスが出るようになっています。

連載の最後は、リリースが間近のWASMについて、コンパイル方法、仕様、そしてJavaScript APIについてご紹介します。

WebAssemblyとは

WebAssemblyとはプログラムを表すファイルフォーマットの一種で、拡張子には.wasmを利用することが一般的です。 Webで扱うファイルの大半はテキスト形式ですが、WASMはバイナリ形式でプログラムを表現します。 バイナリエディタを用いてWASMファイルを作成することも、もちろん可能ですが、Emscriptenに代表されるコンパイラを使って出力することが一般的です。

仕様はW3CのコミュニティグループのメーリングリストやGitHubで議論が行われています。議論の指針は次の4つです。

• 高速で効率的に実行できつつも、ポータブルであること
• ソースを表示できること
• 安全であること
• Webを破壊しないこと。つまり他のWeb技術と組み合わせることができること

このコミュニティグループには、Google、Microsoft、Apple、そしてMozillaの各ブラウザベンダが参加しています。実装もそれぞれに進んでおり、Firefoxでは　52で、Chromeでは57でそれぞれ標準サポートされました。EdgeとWebkitは開発の途中です。Edgeの開発版でAngryBotsが動作している様子は、こちらの動画で確認できますし、Webkitの状況はこちらで確認できます。

WASMの想定される利用例は？

現在のところ想定されているWASMの利用方法は次の3パターンです：

1. アプリ全てをWASMで実装する：C/C++で書かれたアプリをWebに移植するための手段
2. WASMでほとんどを実装し、UIなどをWeb技術で実装する
3. Webアプリケーションのうち、速度が必要な部分をWASMで実装する

1はWebを新しいアーキテクチャとみなし、C/C++のソースコードをクロスコンパイルする、というイメージです。この典型例はゲームでしょう。iOSやAndroid、PS4、Xbox One、PCなど様々あるゲームプラットフォームにWebが加わり、いくつかのプラットフォームへゲームをリリースするのと同じようにWeb向けにゲームをリリースする、というイメージです。

2は既に持っているCやC++の資産を活かしつつ、リッチなUI/UXを提供するといった使い方です。例えば画像認識エンジンや、動画像処理エンジンをすでに持っていて、これらをサービス化したい、といった場合です。それらのエンジンをWASMに変換した上で、UXやUIはWebの技術や開発手法を利用して提供することで、お互いの良いところを取ることが可能です。

3は暗号や圧縮・展開、画像処理といった重たい処理の高速化にWASMを利用する、といった使い方です。asm.jsがよく使われてきた用法でもあります。サーバサイドであれば、Rubyが遅くなってきたのでRustで書き換える、Pythonでは辛いからGoで、といったことがよく行われてきました。フロントエンドではそのようなことは難しかったのですが、WASMを使うことで、アルゴリズムの改良などへ踏み込まずに高速化を行えるようになります。

EmscriptenでWebAssemblyを出力するには

テキスト形式のプログラムからWebAssemblyを変換して出力する方法は、概ね次の3つになります：

1. C/C++で書かれたソースコードをEmscripntenで処理して出力する
2. Rustで書かれたソースコードをコンパイルして出力する
3. WAST（WASMのテキスト形式）で書き、それを変換して出力する

現在のところは1が最も事例の多い変換方法でしょう。Emscripten自身のインストール方法は前回の記事をご覧いただくとして、ここではWASMを出力できるように設定を行い、Hello,Worldをコンパイルするところまでを説明します。

EmscripntenでWASMを出力するためには、開発版とBinaryenというツールが必要です。どちらもemsdkを利用してインストールできます。

$ emsdk install sdk-incoming-64bit emscripten-incoming-64bit clang-incoming-64bit
$ emsdk activate sdk-incoming-64bit emscripten-incoming-64bit clang-incoming-64bit

アクティベート後は忘れずに環境変数を更新しておきます：

$ source ./emsdk_evn.sh

では次のHello,WorldをWASMに出力します。 まず次のようなC言語で書かれたソースコードを用意します。

#include <stdio.h>

int main(int argc, char **argv){
  printf("Hello, World!\n");
}

このコードをEmscriptenを使ってコンパイルします。

$ emcc -o hello-world.html -s WASM=1 hello-world.c

• -oオプションでHTMLファイルを出力すること
• -s WASM=1を指定すること

この 2 つがポイントです。特に-s WASM=1をつけないと、asm.jsが出力される点にご注意ください。

出力されたWASMファイルが動作しているかどうかは、出力されたHTMLファイルをブラウザで表示させることで確認できます。asm.jsなどはファイルを直接開いて実行を確認できましたが、WASMでは行えません。これはWASMの実行時にはクロスオリジン要求が必要で、それがfileスキームには実装されていないためです。そのため簡易なWebサーバを起動する必要があります。任意のものをお使いいただけますが、Emscriptenに同梱されているemrunコマンドを利用すると設定やインストールをしなくても簡易なWebサーバを起動できます。

$ emrun emrun --no_browser --port 8080 .

上記のコマンドを実行すると、コマンドを実行したフォルダをドキュメントルートとしたWebサーバが、8080番ポートで実行されます。こちらへアクセスすることで、動作を確認できます。

WASMモジュールの構造

実はWASMのMVP(Minimal Viable Product/最低限の目標)はasm.jsとの互換機能の提供でした。つまりWASMはasm.jsでできることはできると思っておくと、概ね間違いはありません。例えばasm.jsファイルはソフトウェアモジュールを定義していましたが、同様にWASMファイルもソフトウェアのモジュールを定義します。

とはいえディテールは大きく異なります。asm.jsは（低水準とはいえ）JavaScriptとして処理できる形式でモジュールとその関数本体を定義していたのに対し、WASMは仮想的なハードウェアで動く低水準な命令の集まりとしてモジュールを定義します。WASMはその仕様で型付けされたスタックマシンを定義しており、WASMファイルにはそのスタックマシンで動作するモジュールの抽象構文木（AST：Abstruct Syntax Tree）が定義されています。 抽象構文木がバイナリ形式で与えられているおかげで、ネイティブコードを出力するために必要な処理の中で重たい字句解析の全てと、構文解析の大半を省くことができます。

さてWASMファイルはプリアンブルと、モジュール定義の2つの部分から成っています。プリアンブルはWASMファイルであることを表すマジックナンバー（32bit）と、バージョン番号（32bit）の2つのフィールドで構成されます。モジュール定義は次の7種類のセクションを持ち得ます。依存関係はありますが、これらの全てを省略することもできます。

asm.js同様、WASMでも関数は全て型付けされます。その型が列挙されているのがtypeセクションです。関数の型は引数の型と返り値の型を組み合わせて定義します。例えば次のような足し算を行う関数は(i32, i32) -> i32のように型付けされます。

int add(int a, int b){
  return a + b;
}

このような関数の型のことを「シグネチャ」と呼びます。シグネチャには、それぞれidが割り振られます。このidを用いて、個々の関数を型付けしていきます。個々の関数と、その関数のシグネチャの対応づけが行われるのがfunctionセクションです。上記の(i32, i32) -> i32というシグネチャのidが0の時、次の2つの関数は0番目の関数（addのこと）のシグネチャは0、1番目の関数（subのこと）のシグネチャは1、というようにfunctionセクションへ記述されます。

int add(int a, int b){
  return a + b;
}
int sub(int a, int b){
  return a - b;
}

それぞれの関数の本体、つまり関数定義の{と}に挟まれた部分は、codeセクションに記述されます。このセクションに記述される内容については節を分けて説明します。

上述したように、WASMはモジュールを定義します。つまりWASM内で定義された関数のうちいくつかは外部へと露出します。逆に外部で定義された関数を読み込んで関数を定義することもあります。露出する関数や読み込まれる関数は、それぞれexportとimportのセクションに記述されます。

Memoryセクションには、このモジュールで利用するヒープ領域の初期サイズが設定されます。WASMのメモリは後述しますが線形で、最大4GiBまで利用できます。このセクションで定義されるメモリサイズはあくまで初期化時に割り当てられるもので、grow_memory命令でより多くのメモリを確保できます。

これら以外のセクションもモジュールの定義に必要とされることがありますが、今回は説明を割愛します。詳しくはこちらのデザイン文書をご覧ください。

WASMで定義される抽象構文木

ここまで述べてきたWASMの特徴をまとめると、次の3点になるでしょう。

• バイナリフォーマット
• モジュールの定義
• 型付けされたスタックマシンで動作する抽象構文木を表している

ここからはより詳しくWASMの構造と、それが表す抽象構文木について見ていきます。

そのために　WASMのテキスト表現であるWASTを利用します。このWASTは現在仕様が議論中のため、将来的に記法が変わる可能性があることにご注意ください。

さてa = 1 + 2 * 3;という式は、WASTでは次のように表現されます。

(set_local $a
  (i32.add
     (i32.const 1)
     (i32.mul
        (i32.const 1)
        (i32.const 2)
     )
  )
)

このようにとても括弧が多いのがWASTの特徴です。この記法はS式と呼ばれるもので、LISPというプログラミング言語でよく用いられるもので、木やリストの形式的な記法です。(と)で囲まれたものがノードとなり、その間に挟まれた別のノードは子ノードとなります。先ほどのWASTは次の図のような木構造を表しています。

set_local、i32.add、i32.mul、i32.constというのが、WASMの仕様でで定義されているスタックマシンの命令です。それぞれローカル変数への代入、加算、乗算、即値の定義を行います。四則演算や速値の定義を行う演算子は、扱うデータ型によって異なるものが用意されています。関数本体はこのように記述され、codeセクションに格納されます。

先ほどのWASTを使って、引数に1+2*3の結果を足す関数は次のように記述できます。詳しくは説明しませんが、なんとなく雰囲気は伝わってくるかと思います。

(module
  (func $addSome (param i32) (result i32)
    (local $a i32)
    (set_local $a
       (i32.add
          (i32.const 1)
          (i32.mul
            (i32.const 1)
            (i32.const 2))))
    (get_local 0)
    (get_local $a)
    (i32.add))
  (export "addSome" (func $addSome))
)

なお、このWASTはスタックマシンの性質をうまく使えていません。その特徴をうまく使うと、次のようになります。

(module
  (type (;0;) (func (param i32) (result i32)))
  (func (;0;) (type 0) (param i32) (result i32)
    (local i32)
    i32.const 1
    i32.const 1
    i32.const 2
    i32.mul
    i32.add
    set_local 1
    get_local 0
    get_local 1
    i32.add)
  (export "addSome" (func 0)))

またコンパイラで最適化処理を行うと、次のように単純化されます。1+2*3の結果をコンパイル時に計算を済ませてしまって定数とすることで、不必要な計算を省いています。

(module
  (type (;0;) (func (param i32) (result i32)))
  (func (;0;) (type 0) (param i32) (result i32)
    get_local 0
    i32.const 7
    i32.add)
  (export "addSome" (func 0)))

WASMの構造を把握するには、The WASM Explorerというサイトを利用されるといいでしょう。 このサイトでは、C/C++のプログラムとWASM、Firefoxによって変換されるx86のアセンブラとを比較できます。 Emscriptenで出力されたものと比べると、標準ライブラリで定義されるシンボルや関数が含まれないためコンパクトで、理解しやすいものが出力されます。

WASMで扱えるデータ型

WASMで扱えるデータ型は次の4つです。

整数型と浮動小数点型とを区別して扱える点が、通常のJavaScriptとは異なります。また64bitの整数が扱える点もJavaScriptやasm.jsとも異なっています。

それぞれのデータ型に対して、四則演算、比較演算、即値、データのロードとストアなどの演算子が用意されています。また整数型に対してはビット演算子が、浮動小数型に対しては切り捨て、切り上げなどの演算子が用意されています。

また型間のデータ変換のための演算子も用意されています。32bitから64bitへの変換だけでなく、64bitから32bitへの変換も行えます。もちろん整数から小数へ、小数から整数への変換も行えます。

線形メモリ

WASMの命令セットはスタックマシン型として設計されていますが、メモリに対するアクセスも行えます。WASMのメモリモデルには次の特徴があります：

• 線形
• バイト単位でアクセス可能
• ページ(64KiB)を単位としたメモリの増加
• コード領域はない
• リトルエンディアン
• 最大4GiB

メモリスタックへのデータの読み込みは各データ型の持つload演算を使って行います。WASMはC/C++コードから生成されることを念頭に置いているため、load演算には、i32.load_8_sやi32.load_16_uのようなWASMにはない8bitや16bitのintをロードするものがあります。これらの命令はメモリ上では8bitや16bitの大きさを持つ値を、自動的に32bitへと拡張します。

同様にメモリへのデータ書き込みはi32.storeのようなストア演算で行います。ストア演算も各データ型ごとに用意されており、整数型に対してはi32.store8やi32.store16のように一部分だけを保存する演算も用意されています。

上述したようにWASMのメモリは線形で、0から順にアドレスが付いています。ロード演算やストア演算はアドレスを使って、読み書きするメモリ上の位置を指定します。現在のところアドレスは32bitの符号なし整数で表現されます。そのため利用できるメモリの大きさは4GiBに制限されます（この制限はのちに解消される予定です）。

メモリは常に4GiB確保されるわけではありません。初期化時に確保される量はモジュールで定義します。プログラムの中でgrow_memory演算を行うことで、このサイズを増やせます。また現在のメモリサイズはcurrent_memory演算で取得できます。これら2つの演算はメモリをバイト単位ではなく、ページ単位で扱います。ページサイズは64KiBのため、実際のサイズはページ数に65536(16 × 1024)をかけた値になります。

JavaScript API

ここまでWASM自体について説明してきましたが、最後にJavaScriptとの連携について説明します。今の所、WASMはJavaScript APIを利用して、明示的にコンパイルし、インスタンス化する必要があります。手順としては次の通りになります：

1. WASMファイルをダウンロードし、TypedArrayに変換
2. WASMモジュールがインポートする関数を用意する
3. 1と2を利用して、WASMモジュールをインスタンス化する

この手順をコード化すると次のようになります。下記の例では、上述したsample.wasmをインスタンス化し、そのモジュールに定義されているaddSomeを呼び出しています。

const importObject = {
  hello: () => console.log("Hello"),
  world: () => console.log("world")
};

fetch("sample.wasm").then(response => response.arrayBuffer())
  .then(buffer => WebAssembly.instantiate(buffer, importObject))
  .then(({module, instance}) => console.log(instance.exports.addSome(1)));

WebAssembly.instantiateが、モジュールのインスタンス化を行う関数になります。第1引数にWASMファイルがロードされたArrayBuffer演算を、第2引数にはモジュールがインポートする関数や値をまとめたオブジェクトを指定します。上の例ではhelloとworldという2つの関数がsample.wasm内にインポートされます（実際にインポートされるかどうかは、importセクションの記述によります）。

インスタンス化されたされたWASMモジュールは、JavaScriptのモジュールのように扱えます。変数へ代入することもできますが、属性を追加することはできません。モジュールインスタンスはexportsという名前の属性を持っており、その値のオブジェクトのメンバーとしてエキスポートされた関数を参照できます。

なおWebAssembly.instantiateの呼び出し時には、ダウンロードしたWASMモジュールの妥当性や、ファイルフォーマットの検証が行われます。これらに失敗した場合は、WebAssembly.CompileErrorが送出されます。これをcatchすることでコンパイルエラーを検出できます。

まとめ

これまで4回にわたってポータビリティや後方互換性との両立を図りつつ、ネイティブに近いスピードでの動作を実現するために行わている様々な工夫の一端を見てきました。

asm.jsとWebAssemblyによってネイティブに近い動作スピードは実現されつつあり、それを作成するツールもEmscriptenを筆頭に充実しつつあります。いずれフロント部分のほとんどがCやC++で実装されたWebアプリも登場するでしょう。

ではJavaScriptの役割は終わってしまったのでしょうか。

そんなことはありません。まずWebアプリの大半はasm.js/WebAssemblyで提供される計算性能を必要としていません。必要したとしても、大半のコードの価値はスピードよりもUXによって提供されるでしょう。JavaScriptの大きな特徴は、その生産性の高さです。高速に動作することよりも、高速に開発のイテレーションをまわ回して行く方が重要とされる局面は多くあるでしょう。そんな時にJavaScriptの生産性の高さが生きるでしょう。

ただasm.js/WASMがWebに大きな可能性を加えるものになるのは確かです。既存のWeb開発では難しかったインタラクションの多い3Dグラフィクスを扱うアプリも、UnityやUnrealEngine、Stingrayといったasm.js/WebAssemblyに対応したゲームエンジンを利用することで、効率的に開発できるようになります。工数の関係で諦めていたような表現やアプリの提案も、これらのツールを採用することで可能になる場合もあるでしょう。この連載で扱ってきた技術が、みなさまのWeb開発の選択肢に加わり、その結果Webが豊かになれば幸いです。

間が随分と空いてしまいましたが、低水準言語とasm.jsとWebAssembly詳解の第3回目です。

前回は、型システムを中心にasm.jsを解説しました。asm.jsはプログラムの中に型が明示されるため、事前コンパイルをして高速に動作させられる点がasm.jsの大きな特徴でした。

しかし数値演算しか行えなえず、また式にすべて型アノテーションを行わなくてはならないため、通常のJavaScriptのプログラムのように手で書くのはなかなかに辛いものがあることもわかりました。

これはasm.jsで書かれたプログラムは、JavaScriptとしても実行可能であることが求められたためでもありました。そこでasm.jsよりも書きやすい言語で書かれたプログラムを、asm.jsに変換するツールが提案されています。

そのもっともよく使われている例であるEmscriptenについて、インストール方法や簡単な使い方、ファイルアクセス、そしてJavaScriptとの相互連携までを解説します。

トランスコンパイラ Emscripten

Emscriptenはオープンソースのトランスコンパイラで、コンパイラフレームワークであるLLVMを利用して実装されています。これを利用することで、C言語やC++で書かれたプログラムをasm.jsに変換できます。

たとえば次のCで書かれたHello,worldもEmscriptenを使うと、asm.jsに変換され、Node.jsやWebブラウザで実行できます。

#include <stdio.h>
int main(int argc, char** argv){
  printf("Hello, world!\n");
  return 0;
}

変換に利用するのがEmscriptenのフロントエンドであるemccコマンドです。これをgccのように使って、.cファイルをコンパイルします。次の例では、上記のHello,worldをasm.jsに変換し、Node.jsで実行しています。

3行目に出力されている”Hello,world!”は、Node.jsが出力しています。Cで書かれたプログラムが、Node.jsの上で動作する、というのはなかなか味わい深いものがありますね。

$ emcc -o hello.js hello.c
$ node hello.js
Hello, world!

Emscriptenは、自分の書いたプログラムだけでなく、libcやlibc++といった標準ライブラリも一緒に変換します。

上記の例ではCの標準関数も一緒に変換が行われているため、printfが正しく実行されています。

またOpenGLの関数呼び出しはWebGLへ変換されます。SDLの関数も利用できるため、次のようなSDLを用いたプログラムも変換できます。

これらはCanvas要素をディスプレイ代わりに利用するため、変換時にJavaScriptだけでなくHTMLも合わせて出力させることで実行できます。

$ emcc -o hello-world-sdl.html hello-world-sdl.cpp

Emscriptenのインストール

Emscriptenはemsdkというツールを利用してインストールします。このツールは単なるインストーラではなく、nvmやrustup、rvmのようなツールで、使用するEmscriptenのバージョン指定や更新を行えます。

emsdkとEmscriptenのインストールは配布元のサイトで確認いただけますが、概要を述べると次のようになります。

1. 依存するツールのインストール：GCC/Git/Cmake/Python 2.7.x 2.emsdkのクローンと更新
2. 最新版のEmscriptenのインストール
3. インストールしたEmscriptenの有効化

emsdkはGitHubで配布されています。また内部の処理にGitを利用します。またEmscriptenのインストールや更新時にclangのコンパイルを行います。cmakeやgccはそのコンパイルに利用されます。

環境によってインストール方法は異なります。それぞれの環境にあった方法でインストールしてください。Homebrewを利用できるようになっているmacOSの場合、GCC/Git/Pythonはすでにインストールされています。CMakeは次のようにbrewコマンドを使ってインストールできます。

$ brew install cmake # cmake のインストール

依存するツールをインストールしたらemsdkをクローンします。

$ git clone https://github.com/juj/emsdk.git
$ cd emsdk

emsdkフォルダ内にある、emsdkというファイルを使って、Emscriptenの管理を行います。

まずupdateコマンドを実行して、emsdkそのものと、インストール可能なEmscriptenのバージョンリストを最新のものへと更新します。次にinstallコマンドを実行して、最新の安定板をインストールします。

$ ./emsdk update
$ ./emsdk install latest

インストールしただけでは、Emscriptenを利用できるようにはなりません。activateコマンドで利用するEmscriptenのバージョンを指定し、環境変数を設定することで、インストールした最新バージョンのEmscriptenが利用できるようになります。

$ ./emsdk activate latest
$ source ./emsdk_env.sh

Hello, world!

asm.jsへのコンパイルはemccコマンドを利用して行います。まずは正しくインストールできたかどうかを確認するために、バージョン番号を表示させてみましょう。

$ emcc -v

バージョン番号が表示されれば正しくインストールできています。次はHello,worldでしょう。次のようなプログラムを作成し、hello.cという名前で保存します。

#include <stdio.h>

int main(int argc, char** argv){
  printf("Hello, world!\n");
  return 0;
}

プログラムを作成したら、つぎのコマンドを実行します。

$ emcc hello.c

a.out.jsというファイルが作成されます。これが上記のプログラムがEmscriptenによって変換された結果です。nodeで実行させてみましょう。

ターミナルに”Hello,world!”と出力されるはずです。

$ node a.out.js

emcc コマンド

emccコマンドには、いくつものオプションがあります。それらのうち、よく使うものをまとめると次の表になります。

-oオプションを使うと出力するファイル名を指定だけでなく、ターゲットの変更もできます。 例えば.htmlで終わるファイル名を指定することで、HTMLを出力できます。

$ emcc -o hello.html hello.c
$ ls
hello.c		hello.html	hello.js

出力されたHTMLファイルをブラウザで表示させると、次のように”Hello,world!”と出力されていることが確認できます。

ファイルも扱えます

Node.js同様、C/C++のプログラムはファイルに対する操作が行えます。C/C++の標準的なライブラリで提供されている機能を利用してreadme.txtというファイルを読み込むプログラム実装すると、次のようになります。

#include 

int main(int argc, char** argv){
  FILE *file = fopen("readme.txt", "r");
  while(!feof(file)){
    char c = fgetc(file);
    if(c == EOF){
      break;
    }
    putchar(c);
  }
  fclose(file);
  return 0;
}

このコードの中のfopen,feof,fgetc,fcloseがファイルアクセスに関する関数になります。これらの関数の呼び出しは同期的に行われます。このコードもEmscriptenで変換できますし、正しく動作します。

そもそもブラウザ内で動作するJSはファイルにアクセスできません。

また、このコードはファイルアクセスが同期的に処理されているため、そのまま変換を行うとアクセスが終わるまで、ブラウザの処理が止まってしまいます。下図のような仮想的なファイルシステムを提供することで、Emscriptenはこれらの問題を解決しています。

File System Overview より引用

まずSynchronous File System APIによって、同期的な関数呼び出しを非同期的なものに変換しています。

このAPIはファイルシステムの実装も隠蔽しています。通常はメモリ上に構築されるファイルシステムを利用しますが、コンパイル時のオプションによってNode.jsのファイルシステムや、IndexedDBを利用したものを利用できます。この切り替えを行ったとしても、コードを変更する必要はありません。

Emscriptenの仮想ファイルシステムはPOSIXのファイルシステムと同様に、デバイスファイルの作成や、ファイルシステムのマウントなどもサポートしています。

これらの機能はFileSystem API 経由で利用できます。標準入出力も自作のオブジェクトに置き換えられますので、なかなかに工夫しがいのあるかと思います。

アセットを追加するには

上記の例で利用したreadme.txtのようなアセットを利用するためには、Emscriptenによって提供される仮想ファイルシステムにアセットのファイルを追加する必要があります。

追加方法には、次の2つがあります。

ファイルサイズの大きいものや更新が頻繁なものは後者で、そうでないものは前者の方法を利用するとよいでしょう。

• 利用するファイルをJSに埋め込む方法
• 利用されるファイルを1つにまとめ、それをXHRで読み込む方法

前者は--embed-fileオプションを、後者は--preload-fileオプションをつけてemccを実行することで、利用できます。

例えば先ほど紹介したプログラムはreadme.txtというファイルを読み込み、その内容を標準出力へと出力します。これを後者の方法で変換するには、次のようにemccコマンドを実行します。

$ emcc -o read-file.html --preload-file readme.txt read-file.c

実行すると、HTMLファイルやJSファイル以外に.dataファイルが作成されます。

これはアセットを一つにまとめたものです。このファイルを非同期に読み込み、メモリ上に配置することで、Emscriptenはアセットのロードを実現させています。

文章はWikiPedia のEmscriptenの項目 より引用

インライン JavaScript

C/C++には、インラインアセンブラという機能があります。これはアセンブラで書かれたコードをソースコードの中に埋め込んでしまえる、というもので、高速化やシステムコールの実現などのために利用されます。

同様にEmscriptenでは、ソースコードの中にJavaScriptを埋め込めます。JavaScriptを埋め込むことで、C/C++のコードからブラウザの機能を利用できるようになります。

埋め込むためにはEM_ASM()と呼ばれるマクロを使います。

alert関数を呼び出すコードは、次のように書けます。

#include 

int main(){
  EM_ASM(
    alert("Hello, world!");
  );
  return 0;
}

これをemccでコンパイルして、実行した結果は次のようになります。

EM_ASM_を利用すれば、パラメーターを与えることもできます。EM_ASMとの違いは、埋め込むJSのコードがブロックになっている点と、マクロの名前です。パラメータを与えるマクロは、末尾に_がついています。間違えがちなので注意が必要です。

#include 

int main(){
  EM_ASM_({
    alert(`Hello, world: ${$0}`);
  }, 100);
  return 0;
}

与えられたパラメータは、$0,$1のように参照できます。上記の例では、与えられたパラメータをテンプレート文字列内で利用しています。

これらのマクロはemscripten.hに定義されています。詳しくはドキュメントを参照してください。

外部関数としてJavaScript関数を呼び出す

マクロとしてJavaScriptを埋め込む以外に、C/C++からJavaScriptの関数を呼び出せます。それは外部関数として関数を宣言しておき、Emscriptenの--js-libraryオプションで実装を与える方法です。

次のコードでは、zeroという関数を呼び出しています。この関数は外部の関数として宣言されています。、コンパイラは名前、引数の数と型、返り値の型以外わかっていません。

extern int zero();

int one(){
  return zero() + 1;
}

通常のC/C++では、C/C++のコード（時にはコンパイル済みのバイナリ）として、この関数の実装は与えられますが、Emscriptenでは、これらに加えてJavaScriptでその実装を与えることもできます。

次のようにJavaScriptでzeroを実装し、LibraryManagerオブジェクトのlibrary属性にマージしてやることで、C/C++のコードから呼び出せるようになります。

function zero(){
  return 0;
}

mergeInto(LibraryManager.library, {
  zero: zero
});

JavaScriptから変換されたコード利用するには

基本的な機能はC/C++で実装済みで、それを操作するUIをWebで提供したい。そんな場合は、Emscriptenで変換されたC/C++のコードを、JSから呼び出すかたちで実装するとよいでしょう。

まず基本であるCで定義された関数をJSから呼び出してみましょう。次のような足し算を行う関数が、add.cというファイルに定義されていたとしましょう。

int add(int a, int b){
  return a + b;
}

これをemccコマンドでJSに変換します。

% emcc -o add.js -s "EXPORTED_FUNCTIONS=['_add']" add.c

-sオプションを使うと、コマンドラインオプションでは指定できない内部的なオプションを指定できます。

これを利用してJSへエキスポートする関数のリストであるEXPORTED_FUNCTIONSを設定しています。このリストに載せる関数は、その名前の先頭に_をつけなければならないことに注意してください。

またC++の場合は、関数がマングリングされるの防ぐために、次のようにCのプログラムとして記述する必要があります。

extern "C"{
  int add(int a, int b){
    return a + b;
  }
}

生成されたadd.jsをロードした後、次のようにJS側でasm.jsの関数をラップしたJavaScriptの関数を作成します。

const add = Module.cwrap("add", "number", ["number"]);

Moduleオブジェクトは、Emscriptenによって自動的に定義されるオブジェクトで、生成されたコードが実行されるときに、さまざまな形で利用されます。そのcwrapメソッドを使って、asm.jsの関数をJavaScriptから利用できるようにします。そのメソッドの引数はそれぞれ、ラップする関数の名前、返り値の型、引数の型を表します。

一度ラップされてしまえば、JavaScriptの関数と区別することなく利用できます。

const sum = add(1, 2); // 3
console.log(sum);

C++で書かれたコードに対しては、上記の方法に加えて、C++で定義されたクラスをJavaScriptから利用できるようになります。これの詳細については述べませんが、手順を概観すると次のようになります：

• C++で定義されたクラスのためのWebIDLを作成する
• 作成したWebIDLをtools/webidl_binder.pyで処理して、グルーコードを作成する
• グルーコードとともに、cppファイルをemccコマンドでコンパイルする

上記の手順で処理することによって、C++で定義されたクラスを作成するコンストラクタが、Moduleオブジェクトの属性として参照できるようになります。

詳しくはこちらのドキュメントを参照してください。

まとめ

手で書くのが大変なasm.jsも、CやC++で書いたコードをEmscriptenで変換することで簡単に生成できます。このとき標準ライブラリの変換も合わせて行われます。

またファイルシステムもEmscriptenによってエミュレートされるため、asm.jsへの変換を行う際にソースコードを変更する必要はほとんどありません。C/C++のコードをほとんど変えなくても、asm.jsへと変換できます。

またJavaScriptと変換されたコードの相互呼び出しも可能な上に、標準入出力もJSでエミューレートできます。そのおかげで、Emscriptenで作られたasm.jsコードと、JavaScriptで作られたコードとを柔軟に組み合わせてサイトやアプリを作ることができます。

これでめでたしめでたし、とならないのが技術の世界のつらいところです。Emscriptenによって作られたコードにも弱点があります。それはロードにかかる時間です。単なるHello Worldであっても、変換されたコードは300Kバイト程度になります。これは合わせて変換された標準ライブラリが、コードに含まれているためです。

コードのサイズは、Hello Worldなので300K程度で済んでいるともいえます。これがゲームともなれば、そのサイズはさらに増大します。コードサイズの大きさは、ダウンロードにかかる時間が大きいことも意味しますし、ダウンロード後、起動までの時間が長くなることも意味します。

この問題を解決するために、新しいファイルフォーマットの議論が始まりました。それがWebAssemblyです。

上の表をご覧いただければ、WebAssemblyを利用することでファイルサイズがぐっと小さくなっていることがわかるかと思います。最終回となる次回はWebAssemblyの役割と、その特徴について解説します。

連載の第１回目は asm.jsの紹介と、asm.jsが導入された背景を概観しました。

Just in Timeコンパイルによって高速にJavaScriptを実行できるようになりましたが、立ち上がりが遅い、やり直しが発生する、コンパイルによって一時的に負荷が向上する、といった問題が残されています。

これを解決するためにプログラムの実行を行うより前にネイティブコードへとコンパイルするAhead of Timeコンパイルを導入したいのですが、JavaScriptは柔軟すぎて効率の良いネイティブコードを出力することが難しい、という問題がありました。

asm.jsはこの問題に一定の解をあたえるものとなります。今回はそのasm.jsがどのようなものなのか、JavaScriptの関数を asm.js化しながら解説していきます。

asm.jsがコンパイルされるまで

前述したとおりasm.jsで記述されたプログラムは、実行以前にコンパイルされます。コンパイルは下図のような過程で行われます。

ソースコードが字句解析、構文解析されてAST（Abstract Syntax Tree：抽象構文木）になるところまでは一緒ですが、その後意味解析が行われます。この意味解析でそれぞれの式や変数、関数の型がチェックされます。

意味解析が終了後、プログラムはコンパイルされネイティブコードが出力されます。このネイティブコードはメモリ上に展開されたあと、プログラム中で利用しているJavaScriptの関数やasm.jsに用意されている標準ライブラリとのリンクが行われます。

意味解析とリンク、この2つに失敗する場合もあります。プログラム中に型エラーが発見された場合は前者の失敗します。 後者はメソッドの呼び出しや、JSにエキスポートできない種類のデータを引数に指定した関数呼び出しを行った場合に失敗します。

このような場合、プログラムはasm.jsとして処理されるのではなく、通常のJSとして処理されます。asm.jsがJSのサブセットであることによって、このようなフォールバックも可能になっています。

asm.jsモジュール

asm.jsで書かれたプログラムとして事前コンパイルされる際の単位は、モジュールです。ファイル単位でコンパイルが行われるわけではないので、1つのJSファイルのうち高速化が必要な部分をasm.jsで書き、それ以外の部分は通常のJSとして書くといったことが可能です。

asm.jsのモジュールは、次のようにCやC++のソースコードと似た構造となっています。

function ModuleName(stdlib, ffi, heap){
"use asm";
 // (1) 外部からインポートするシンボルの宣言
 // (2) 関数宣言
 // (3) 関数表の宣言
 // (4) モジュールのエキスポート
}

1の部分では利用する標準ライブラリや、JSの関数、定数などのシンボルを列挙します。ちょうどCのextern宣言と同じような役割です。

2の部分で、それぞれの処理を関数として定義します。asm.jsではオブジェクトやクラスの定義が許されていません。そのため処理はクラスやオブジェクトとしてではなく、あくまで関数として定義します。

3の部分では同じ型の関数をまとめた表を定義できます。ちょうどCでの関数ポインタの機能を代替するものです。関数を直接呼び出すのではなく、この表を参照する形で呼び出すことで、呼び出す関数の振る舞いを変えられるので、多態性を持った関数を定義したい場合に有用です。

とはいえ、いまいちイメージがつかめないかと思います。そこで足し算を行うモジュールをasm.js化しながら、構成を見てゆきましょう。変更するのは以下のようなモジュールです。

function AddFunctions(){
  function add1(value){
    var result;
    result = value + 1;
    return result;
  }
  return {
    add1: add1
  }
}

このモジュールは次のように利用できます。

const module = AddFunctions();
const one = module.add1(0);    // 1
const two  = module.add1(one); // 2

asm.jsディレクティブ

asm.js化の第一歩は、ディレクティブの追加です。”use strict” ディレクティブをつけると、その関数はstrict modeで解釈されるのと同様に、”use asm”ディレクティブをつけることで、処理系はその関数をasm.jsのモジュール定義として処理します。

function AddFunctions(){
  "use asm";
  function add1(value){
    var result;
    result = value + 1;
    return result;
  }
  return {
    add1: add1,
  }
}

　型アノテーション

次にAOTを行うための型アノテーションを行います。型アノテーションは、TypeScriptなどのように型を直接記述する方法が一般的かと思いますが、JavaScriptとしても解釈できなくてはいけないasm.jsでは異なります。同値となるような式を追加することで、型情報を明示します。

明示的に型アノテーションを行う対象は次の3つです。

• 関数の引数
• 変数
• 関数の返り値

これらの情報を元に、関数の型や式の型が決定されます。

引数に対する型アノテーション

引数に対する型アノテーションは、関数本体の先頭で行います。次の例では、add1の引数valueの型はintであることを示す型アノテーションが加わっています。value = value | 0; が型アノテーションを行っている部分です。

function AddFunctions(){
  "use asm";
  function add1(value){
    value = value | 0;
    var result;
    result = value + 1;
    return result;
  }
  return {
    add1: add1
  }
}

引数で利用できる型はint, doubleの2つです。それぞれの型はは次の表のようにアノテーションします。

尚、外部で定義された関数呼び出しを行った場合は、floatとして解釈されます。

変数宣言

asm.jsでは、関数内で利用する変数に対しても型アノテーションを行います。これは宣言時に初期値として代入するを適切に選ぶ形で行います。整数値を代入すればintに、実数値の場合はdoubleとなります。

尚、1.0のような小数点以下の数字が0のものは実数値として扱われます。変数宣言に型アノテーションをつけると、先ほどまでのモジュールは以下のようになります。

function AddFunctions(){
  "use asm";
  function add1(value){
    value = value | 0;
    var result = 0; // intとして宣言
    result = value + 1;
    return result;
  }
  return {
    add1: add1
  }
}

返り値に対する型アノテーション

返り値に対して型アノテーションを行います。この情報と引数の型情報とを組み合わせて、関数の型が決定されます。

返り値で利用できるのはdouble, signed, float, そしてvoidの4つの型です。それぞれのアノテーション方法は以下の表の通りです。また即値を書く場合は、アノテーションは必要ありません。

asm.jsの型システム

これまでintやdoubleといった型を利用してきましたが、asm.jsで利用できる型を列挙し、それぞれの継承関係を示すと次の図となります。 矢印の元にある型は先の型を継承しています。

http://asmjs.org/spec/latest より引用

継承するということは、何かの制約が厳しくなっていくということです。asm.jsの型システムではnullを許容するか、実行時に割り当てられるレジスタがdoubleかintか、といった点での制約が厳しくなっていきます。

また、JavaScriptで定義されている関数に渡せる型も決まっています。背景色が薄い灰色になっているfixnum / signed / extern / double型のデータのみが許可されています。

型のキャスト

先ほどから変更しているプログラムは、意味解析に失敗します。それは次の部分に原因があります。

result = value + 1;

これはint+fixnumの計算を行い、その結果をint型の変数に代入しようとしています。型エラーの入り込む余地はなさそうに思えます。しかし、この加算の評価値の型はinterishとなっています。そのため、int型へinterish型の値を代入することになり、型エラーが起きるというわけです。

そこでキャストを行い、演算結果の型を明示します。この変更をおこないasm.jsの意味解析に成功するコードは次のようになります。

function AddFunctions(){
  "use asm";
  function add1(value){
    value = value | 0;
    var result = 0; // int として宣言
    result = (value + 1) | 0; // int へキャスト
    return result;
  }
  return {
    add1: add1
  }
}

JavaScriptとの組み込み

以上で、AddFunctionsモジュールをasm.js化することができました。これをJavaScriptのプログラムに組み込みんでいきます。

ここでは 上記で作成したAddFunctionsモジュールをJavaScript側から利用する方法と、AddFunctionsモジュール内で JavaScriptの関数を利用する方法について説明します。

JavaScriptからの利用

asm.jsのモジュールとJavaScriptのモジュールは、JavaScriptからみると区別できません。下記のようにJSのモジュールを呼ぶように利用できます。

const module = AddFunctions();
var one = module.add1(0);
var two = module.add1(one);

function add2(n){
  return module.add1(module.add1(n));
}

JavaScriptの関数をasm.jsから呼ぶには

まず、asm.jsの内部からJavaScriptで定義された関数を呼ぶことはできます。また、Mathオブジェクトの持っているいくつかのメソッドは、標準ライブラリ中の関数として提供されています。

これら関数への参照はモジュールを定義する関数の引数として与えます。例えば、AsmModuleにasm.jsモジュールが定義されている場合、次のように呼び出すことでJavaScriptの関数をasm.js内から呼び出せます。

const ffi = {
  put: n => console.log(n)
};

const module = AsmModule(window, ffi);

asm.jsで定義される関数はオブジェクトの解決ができません。そのため利用する関数はあらかじめ外部からインポートするシンボルとして宣言しておきます。

次の例では、標準ライブラリ中のMath.expとMath.log、そして自作関数であるputを外部からインポートするシンボルとして宣言しています。

function AsmModule(stdlib, ffi, heap){
  "use asm";
  var exp = std.lib.Math.exp;
  var log = std.lib.Math.log;

  var put = ffi.put;

これらの関数は、関数定義内でasm.js内部で定義された関数と同様に呼び出せます。ただ1点注意しなくてはならないのは、引数に渡すデータの型です。標準ライブラリ以外の外部関数に渡せるのはfixnum、signed、extern、doubleのいずれかです。 それ以外の値を渡すとリンクエラーとなり、通常のJSとして実行されます。演算の結果を適切にアノテーションすることで、リンクエラーを避けられます。

var value = 1;
put(value + 1); // リンクエラー
put((value + 1) | 0); // OK

ヒープの利用

asm.jsで定義される関数は、数値演算しかできません。また、オブジェクトの解決もできません。つまり、次のような関数は定義できないことになります。

function caesar(string, key){
  var result = "";
  for(let i = 0; i < string.length; i++){
    result += String.fromCharCode(a.charCodeAt(0)+key);
  }
  return result;
}

ところでC言語では文字列を数値の配列として扱います。この考えを応用すれば、asm.jsでも文字列を数値演算の範囲で扱えるようになります。

上記の関数をasm.jsに書き直すと以下のようになります。

function Caesar(stdlib, ffi, heap){
  "use asm";
  var HEAP = new stdlib.Int8Array(heap);

  function encrypt(key){
    key = key | 0;
    var i = 0;
    for(;(HEAP[i << 0 >> 0] | 0) != 0; i = i + 1 | 0){
      buffer[i << 0 >> 0] = ((buffer[i << 0 >> 0] | 0) + key) | 0;
    }
    return;
  }

文字列はHEAPというArrayBufferに格納されています。このArrayBufferはモジュールの定義時に引数として与えられます。 ArrayBufferのビューは標準ライブラリとして提供されているため、上記のようにモジュール内のHEAPを大域変数として宣言する際にビューもあわせて定義します。

HEAPの添字は、ビューの各要素の大きさに合わせてシフトする必要があります。シフトするビット数は、2を底として要素のバイトサイズのlogをとると求まります。

上記の例で利用しているInt8Arrayの場合、各要素の大きさは1バイトのため、0ビットシフトしています。ビューとシフトするビット数の対応は次の表を参照してください。

ArrayBufferを与えてモジュールの作成と関数の呼び出しを行うと、次のようなコードとなります。

気をつけなければならいのは、TypedArrayの大きさです。2¹² 以上、2²⁴バイト未満の大きさになるようにするか、2²⁴バイトの整数倍の大きさになるようにしてください。そうしなければ、リンクに失敗してします。

これが原因でリンクに失敗した場合は、コンソールに適切なサイズが表示されます。それを参考に大きさを際設定すればようでしょう。

const heap = new Int8Array(0x10000)
const caesar = Caesar(window, {}, heap);
heap[0] = 72; heap[1] = 65; heap[2] = 76; // HALと設定
caesar.encrypt(1); // HALが1文字ずつシフトされる

まとめ

以上のように、JavaScriptと比べてasm.jsは随分と書きづらく、できることも限られています。ArrayBufferを駆使すればベクトルの計算も可能ですが、オブジェクトと平坦なArrayBufferとの相互変換を自分で実装しなくてはならず、なかなか骨が折れる作業であることは否めません。

その代わり得られる効果は絶大です。JITによって処理が重たくなることもなく、高速な実行が可能となります。またコンパイルされた結果はキャッシュされるため、2回目以降は高速に起動できるようになります。

とはいえ、手で書くのは骨が折れます。

「人間のやることではない」

「高級言語で実装したい」

そう思う方も多いでしょう。そのために用意されているツールがEmscriptenです。次回はEmscriptenを利用したC言語やC++で実装されたコードのasm.jsへの変換について解説します。

Webブラウザの上で動作するアプリを書くための言語、といえば何が想起されるでしょうか。Flash、Sliverlight、Java、さまざまな言語が利用されてきましたが、やはり今のメインストリームはJavaScriptでしょう。

JavaScriptはさまざまな言語の特徴を併せ持つ動的言語で、Web技術の発展とAPIの整備の結果、Virtual Reality(VR)や画像認識、DAW(Desktop Audio Workstation)といった、少し前まではネイティブでの実装しかありえなかった種類のアプリケーションもWebブラウザをランタイムとするJavaScripで実装されるようになってきました。

そのようなアプリの代表例がゲームでしょう。少し前までのブラウザゲームといえば、リロードを繰り返すタイプのゲームか、Flashゲーム、パズルなどの簡単なものが大半を占めていたように思います。Canvasを利用して実装されたスーパマリオやNESエミュレータなどもありましたが、いずれも実験的なものであり、また20年以上前のハードウェアで快適に動くゲームだったことを考えると、CPU時間を大量に消費する「重厚」なものではありませんでした。

しかし最近は重厚なゲームの開発も行われ始めています。この嚆矢はBananaBreadでしょう。これはMozillaのエンジニアチームが開発した複数同時対戦可能なFPS(First Person Shooting)です。このようなゲームの実現が可能になったのは、WebGL、Web Workers、Web Audio API、Gamepad API、IndexedDBなどに代表されるAPIの充実もありますが、既存のJavaScriptエンジンではなしえなかった高速の演算を可能にする、低水準言語の整備のおかげでもあります。

この連載は4回にわたって、Webブラウザ上で動作する低水準言語であるasm.jsと、（いまのところ）そのバイナリフォーマットであるWebAssemblyについて、その設計と仕様、そして開発環境を紹介します。

低水準言語asm.js

asm.jsはMozillaが研究開発したJavaScriptのサブセットで、2013年に発表されました。現在はFirefoxとGoogle Chromeによって実装が行われ、EdgeやSafariも対応を表明しています。その特徴はなんといっても動作の高速さです。次のグラフはasm.js発表時に公開されたベンチマークの結果で、棒グラフが短ければ短いほど、処理が高速であることを意味しています。このグラフによると、ベンチマークの種類にも依存しますが、概ねCやC++によるネイティブ実装の半分程度のスピードで動作していることがわかります。

https://kripken.github.io/mloc_emscripten_talk/cppcon.html#/24より引用

このような高速に動作を可能にしているのは、事前コンパイルと呼ばれる技術です。AOT(Ahead of Time)とも呼ばれるこの技術を利用すると、プログラムはその実行直前にコンパイルが行われ、ネイティブコードへと変換されます。ブラウザは内蔵するコンパイラでasm.jsで書かれたコードをネイティブコードに変換し、ネイティブコードを実行することで、この高速性能を実現しているのです。

事前コンパイルを可能とするために、asm.jsで書かれたプログラムは以下にあげる特徴を持っています。

• 変数や式、関数の型が静的解析可能である
• 数値計算に特化している
• 作成や属性の参照、メソッド呼出といったオブジェクトに関する操作ができない
• 利用できるコレクション型はTyped Arrayのみである

一般のJavaScriptやAngular、RxJSといったモダンなフレームワークの提供するDSL(Domain Specific Language)に 慣れた身からすれば、機能が制限され、「低水準な」印象が拭えません。2013年にもなって、なぜ、このような制約の強い言語が開発されたのでしょうか。もちろんJavaScript発展の文脈に基づく、実用上の要求があるためです。それを理解するに、まずJavaScriptの動作について簡単に（かつ大雑把に）振り返ることとしましょう。

JavaScriptが動く仕組み

プログラミング言語は「コンパイラ型」と「インタプリタ型」の2つに分けることができます。C言語やC++は前者の典型で、 後者の典型はPerlやRuby、Pythonでしょう。JavaScriptも後者に分けられます。インタプリタ型の特徴は、あるプログラムの動作に「インタプリタ」と呼ばれる別のプログラムが必要である点です。SpiderMonkey(Firefox)、Chakra(Edge)、V8(Chrome / Node.js)はJavaScript向けのインタプリタとして有名でしょう。

インタプリタは、文字列を解釈してプログラムとしての文法的構造を取得します。この過程を字句解析・構文解析と呼び、 結果得られた文法的な構造のことを抽象構文木(AST: Abstract Sytactic Tree)と呼びます。例えばa=1+2*3; のASTは次のようになります。

素朴なインタプリタは、この抽象構文木を枝の方から実行していきます。先ほどの例だと、まず2 * 3の計算を行い、 その結果である6で2 * 3に相当する部分木を置き換えます。その後1 + 6を計算し、最後にa = 6を計算します。この場合では、*や+、=といった演算子や標準ライブラリ中の関数などは、インタプリタ中の関数として実装され、それらをASTを解釈する巨大なswitch文の中から呼び出してプログラムは実行されます。そしてこの巨大なswitch文は、プログラムの評価が終わるまで繰り返し実行されます。

仮想マシンとバイトコード

このようなインタプリタはシンプルで理解しやすいのですが、変数のスコープや返り値の受け渡しの実現が困難になりがちです。そこで多くのインタプリタはASTをバイトコードに変換して実行します。バイトコードは単なるASTのバイナリ表現ではなく、インタプリタによって実装された仮想的なハードウェア（仮想マシン）を動かすマシンコード、つまり仮想的なネイティブコードとなっています。例えば(a,b,c)=>a+b*cという関数は、SpiderMonkeyによって次のようなバイトコードの列に変換されます。

getarg 0
getarg 1
getarg 2
mul
add
return
retrval

getargやmul、addなどはSpiderMonkeyの実装している仮想マシンの持つ命令です。仮想マシンには計算に使う値をスタックに保存するスタックマシンと、レジスタに配置するレジスタマシンとがありますが、SpiderMonkeyはスタックマシンを採用しており、変数への代入や、実引数の参照はスタックに対する操作として実現されています。

なおSpiderMonkeyの提供するバイトコードはこちらのサイトで一覧できます。

バイトコードに変わったとはいえ、実行のモデルは変わりません。バイトコードを1つずつとってきては、バイトコードを解釈する巨大なswitch文を通じて、各命令を実装する関数が呼ばれます。これがプログラムの実行が終了するまで繰り返されます。

型情報の不足

どうせネイティブコードを出力するなら、仮想マシンのネイティブコードではなく、実マシンのネイティブコードを出力すればいいのに。そう思われるのも当然ですが、出力しない、もしくはできないのにも理由があります。それらの中で大きなものの1つが、型情報の不足です。

function wrap(value){
  return {value: value};
}

var b1 = wrap(1);
var b2 = wrap(2);
var result = b1.value + b2.value;

resultにはどういう種類のデータが入るでしょうか？数値とすぐわかる方も多いとは思います。ではなぜ数値だとわかったのでしょうか？頭の中で上記のプログラムを実行した結果、b1.valueとb2.valueの値が両方とも数値であることがわかり、 数値同士の加算は数値になることから、resultには数値が代入されると結論づけたのではないでしょうか。

では、このwrapの返り値のvalue属性には常に数値が代入されているでしょうか？wrapの引数は数値でなければならない、とはどこにも書いてありません。そのため、次のような呼び出しも可能です。

var b3 = wrap("abcd");
var b4 = wrap({id: 1234});
var b5 = wrap(null);
var b6 = wrap(undefined);

b3,b4,5,b6それぞれのvalue属性の型も、string,object,null,undefinedと異なる型になっています。 このようにJavaScriptのプログラムは実行するまで変数や演算結果の型がわからないことが多々あります。 これはプログラムの中に型の情報が含まれていないためです。 もし型情報が含まれていれば、実行しなくても変数や演算の結果の型を決められます。 型付けの強い言語の代表例であるRustを使って同様のプログラムを記述すると、次のようになります：

struct Box<T>{value: T}
fn wrap<T>(value:T) -> Box<T>{
  Box{value: value}
}
fn main() {
  let b1 = wrap(1);
  let b2 = wrap(2);
  let result = b1.value + b2.value;
  println!("result = {}", result);
}

このプログラムでは実行しなくても、resultの型はintであることがわかります。resultの宣言からは、型宣言を省略してあります。それでもRustの処理系は他の情報から型を決定して型を決めています。それはBoxとwrapの宣言についている型情報、そしてwrapを呼び出した際の引数から、b1.valueとb2.valueの型が決定できるためです。

さて型がわからないことが、ネイティブコードの出力にどのような影響を与えるのでしょうか。それは端的にいえば、出力するネイティブコードが冗長になるということです。例えばIntelのCPUの場合、加算だけでも20種類以上の命令があります。 これはデータ型と、データの保存場所によって使用する命令が異なるからです。データ型が適切に決定できているなら、使用する命令を1つに絞ることができます。

しかしデータ型を適切に決定できない場合、その可能性を1つずつチェックし、そのチェックした結果に合わせて使用する命令を決めるといったようなコードを出力せざるをえません。その結果コード全体は冗長になり、スピードもあまりでなくなってしまいます。ネイティブコードの出力にも時間がかかるため、その時間に見合った効果が得にくくなってしまいます。

JITコンパイル

ネイティブコードを出力したいが、ソースコードには型に関する情報がない。この状況を打破するために利用されている技術がJIT(Just in Time)コンパイルです。これはJavaScriptをいきなり高速に動かすためのネイティブコードに変換せず、しばらくインタプリタなどで動作させます。変数に代入される値を観察して、その型に関する統計情報を集めます。

この統計情報と、1つの変数には同じ種類のデータが代入される傾向にある、というヒューリスティックを利用してその変数の型を推定していきます。推定がある程度できた時点で、該当するコードからネイティブコードを出力します。このようにプログラムを動かしながら、必要に応じてネイティブコードへと出力するのがJITです。

SpiderMonkeyではJITは2段階に分かれています。まずはnullチェックなどを含んだ冗長なコードを出力するベースラインJIT を行います。その状態でしばらく動作させ、型情報の統計を取得します。ある程度の型情報が集まったところで、その情報を元により効率の良いコンパイルを行います。

図中のIon compileがそれです。

asm.js AOT compilation and startup performanceより引用

型情報が集まったかどうかは実行回数によって決まっているようです。コードをざっと眺めた限り、10回程度繰り返し実行されるかどうかが、コンパイルを行うかどうかの判断の目安になっているようです。

上図のように、コンパイルされたコードは常に維持されるわけではありません。ときにはbail、つまりコンパイル結果を捨てて、もう一度型の推定からやり直します。これはJavaScriptの関数呼び出しに型による制約がかけられず、推定がヒューリスティックによるもののため、仕方がないことです。例えば、次のような呼び出しが行われた場合twiceのコンパイル結果は捨てられてしまいます。

function twice(a){
  return a + a;
}
var array = [0, 1, 2, 3, ... , 100000].map(twice);
var str = twice("こんにちは");

map関数からの呼び出しによってtwiceは10000回実行されます。この途中で（正確には、行われるかどうかは処理系に依存するのですが）、twiceはnumberを引数にとり、numberを返す関数としてJITコンパイルされます。しかし次の行の引数に文字列が与えられた呼び出しによって、その結果は捨てられてしまいます。捨てないとこの処理が行えないためです。

TypeScriptのような型制約があればこのようなことが起きないのですが、残念ながらJavaScriptにはそれがありません。 そのため時には時間をかけて行ったコンパイル結果を捨て、低速に動くことを余儀なくされてしまいます。

まとめ

JITを利用することで、よく利用されるコードを高速に動作させられるようになりました。 それでも次のような問題が残っています。

1. よく使うコードしかネイティブコードにならない
2. 高速に動作するようになるまでにはリードタイムが必要
3. 型の推定には失敗することがある

重厚なゲームのようなアプリケーションの場合、2や3の問題は致命的なものとなりえます。

FPS(First Person Shooting)で対戦している場合を想像してみてください。対戦の最初はコンパイルがすんでいないため、ゲームはもっさりと動作しています。これではゲームになりません。しばらくは自分の陣地でゆっくりしてコンパイルが終わるのを待ちましょう。コンパイルが終わってFPS(Frame Per Second)が出てきました。ようやく本当のゲーム開始です。

そこで相手の攻撃を読み、侵攻して、草むらに潜み、相手がくるの待ち受けます。いざ相手へ攻撃をかけようとした瞬間、3に起因するコードの再コンパイルが発生し、画面がプチフリーズ。ゲームに復帰したら、目の前には銃を構える敵が…

こういう状況を避けるためにも、上述したような問題に対する回避策が求められました。それがAOTとasm.jsでした。AOTによって1,2の問題を回避し、その実現と3の回避のために型情報のふくまれたasm.jsが導入されることとなりました。

次回はasm.jsがどのように型情報を与えていくのか、型アノテーションを中心に解説します。

2013年11月30日（土）に開催された「HTML5 Conference 2013」の、Mozilla Japan浅井智也さんによるセッション「進化を続ける JavaScript ～次世代言語のステキな機能と高速化の行方～」のセッション内容をご紹介します。

JavaScriptの課題と改良への動き

現在のJavaScriptには、次のような課題があります。

• 高速化がなかなかできない
• クラス、モジュールがない
• プロトタイプベースであるため、普段Javaなどでクラスを使っている人にとって、メソッド定義や継承がわかりにくい
• メソッドとして呼び出したときはthisがそのメソッドのオブジェクトになるが、間違って関数として呼び出すとthisがwindowオブジェクトになるなど、thisの挙動を捉えるのが難しい
• argumentsなど、ArrayのようでArrayでなくついarguments.slice()とかしてエラー原因になる、紛らわしいオブジェクトがある
• コールバック地獄
• 実行時エラーが多く、コンパイルエラーが少ないので、デバッグが非常に大変である

JavaScriptの歴史について詳しくは過去の講演資料をご覧ください。簡単に言えば次の資料の通りです。次期ECMAScript 6thでは大きく改定されるため、この改定内容はぜひ知っておく必要があります。

ECMAScript 6thの概要

目標

ECMAScript 6thの目標は、より開発・テストを行いやすくし、相互運用性を確保し、静的検証（コンパイルエラーの検出）を行える構文・言語仕様を提供することにあります。

実装・対応状況

FirefoxのSpiderMonkeyの実装範囲が比較的広く、V8がそれに続く状況になっています。機能によってはV8の方が先に入っていたり、上手く実装されているものもあります。IEは非常に安定した、広く使われている仕様が実装されており、加えて、グローバリゼーション、国際化といったビジネス系の仕様が積極的に提案、実装されています。TypeScriptは、対応範囲がクラスなどに絞られている印象があるのですが、比較的綺麗なコードが生成されます。その他にも、letやconstといったブロックスコープだけを使いたいのでしたらdefs.jsを、あるいはModuleのimport/export機能だけを使いたい場合はes6-module-loaderといったコンパイラも使うことができます。

Syntax Sugar

分割代入 (Destructuring)

これまでのJavaScriptでは代入文の左辺に変数を一つしか指定できませんでしたが、ECMAScript 6thでは左辺に配列やオブジェクトを指定することができるようになります。これにより、例えば、関数から配列やオブジェクトなどで複数の返り値を受け取り、それをそのまま変数に格納するといった処理を記述できるようになります。JSONから特定のデータを抜き出す、といったことを行うこともできます。

// 配列で受け取るサンプル: // 値の入れ替え
[a, b] = [b, a];

// 関数から複数の値を返して一気に変数に代入
var [c,d] = (function f() { return [1,2]; })(); // -> c=1, d=2

// 一部省略や入れ子も可能
var [e,,[x,y]] = (function f(){
  return [3,4,[10,20]]
})();

// オブジェクトで受け取るサンプル
var fx={ name:"Firefox", vendor:"Mozilla", ver:26 };
var ch={ name:"Chrome", vendor:"Google", ver:31 };
var browsers={ firefox: fx, chrome: ch }

// 欲しいプロパティだけ一括代入
var { name: n, ver: v } = fx;
// -> n="Firefox", v=26

// 関数の引数から必要なプロパティだけ受け取る
(function ({ vendor: ven }) {
  console.log(ven);
})(fx); // -> "Mozilla"

default & rest parameter

引数のデフォルト値を設定できたり（default parameter）、関数の残りの引数を配列で受け取ったり（rest parameter）することができます。

e = document.body; // 何か適当な要素
function setBackgroundColor(element, color='orange') {
  element.style.backgroundColor = color;
}
setBackgroundColor(e); // オレンジに
setBackgroundColor(e, 'blue'); // 青に
setBackgroundColor(e, undefined); // オレンジに

// デフォルト値は呼び出し毎に生成される
// 同一オブジェクトが渡される Python などとは違う
function getObject(o={}) { return o; }
getObject() == getObject() // -> false

function f(a, b, ...args) { return args; }
f("IE", "Chrome"); // -> []
f("IE", "Chrome", "Firefox"); // -> ["Firefox"] !

// rest arguments は Array のメソッドが使える
// [].slice.call(arguments) ハックとか不要に
function sortRestArgs(...theArgs) {
  var sortedArgs = theArgs.sort();
  return sortedArgs;
}

配列の内包表記 (Comprehensions)

for…ofなどを使って、直接、配列のリテラルを生成することができます。

// 配列のフィルタとマップ
[for (x of [1,-4,5,3,-7]) if (x > 0) x] // -> [1, 5, 3]
// ES5 なら次のように書く
// [1,-4,5,3,-7].filter(function(x) { return x > 0 });
[for (x of [2,4,6]) x*x] // -> [4, 16, 36]
// ES5 なら次のように書く:
// [2,4,6].map(function (x) { return x*x });

// 配列のデカルト積やラベル生成もシンプルに
[for (i of [0,2,4]) for (j of [5,3]) i*j]
// -> [0, 0, 10, 6, 20, 12]
[for (x of 'abc'.split(''))
 for (y of '123'.split('')) (x+y)];
// -> ["a1","a2","a3","b1","b2","b3","c1","c2","c3"]

Modularity

ブロックスコープ (let, const)

今までのJavaScriptにはブロックスコープがなく、グローバルスコープと関数スコープしかありませんでした。変数をブロックスコープに納めるために、今まではわざわざ関数を作らなければなりませんでしたが、ECMAScript 6thでは、let, constを指定するだけでブロックスコープ変数を作成することができます。

{
  // let 定義: ブロックスコープ
  let a = 1, b = 10;
  // let 式・文: let (...) に続く式・文中だけで有効
  let (a = 100, c = 300) console.log(a); // -> 100
  // for 文などでの let
  for (let a=0; a<3; a++) {
    console.log(a+b); // -> 10, 11, 12
  }
  console.log(a); // -> 1
}
console.log(a); // × ReferenceError: a is not defined

// 不変定数を定義
const browser = "Firefox";

// 再定義は TypeError となる
const browser = "Internet Explorer";
// TypeError: redeclaration of const browser !

// 定数への代入は単に無視される
browser = "Chrome";
console.log(browser); // -> "Firefox"

Class

待望のClassが使えるようになります。他のオブジェクト指向の言語と同じような形式でClassを記述することができます。constructorメソッドが初期化時の処理として使われます。

// クラスベース OOP でよく見る感じ
class Animal {
  constructor(name) {
    this.name = name;
    this.hungry = true;
  }
  eat() {
    this.hungry = false;
  }
  run() {
    this.hungry = true;
  }
}

// 派生クラスの定義がシンプル
class LesserPanda extends Animal {
  constructor(name, tail) {
    super(name);
    this.tail = tail;
  }
}

Module

今まで、モジュールをインポート・エクスポートする様々なライブラリが作られてきましたが、この機能が公式のものとして提供されることになりました。

module 'math' {
  export function sum(x, y) {
    return x + y;
  }
  export var hbar = 1.054571726e-34; // ディラック定数
}

import {sum, hbar} from 'math';
alert("2ħ = " + sum(hbar, hbar));

// オブジェクトのプロパティに読み込み
module Math from 'math';
alert("2ħ = " + Math.sum(Math.hbar, Math.hbar));

Readable Code

Arrow Function

今まで、コールバックとして関数を渡す際に「function(…){…}」と記述する必要があり、ソースコードが冗長で見にくくなっていましたが、Arrow Functionを使うことでこの関数をシンプルに記載できるようになります。

// return するだけのコールバックがシンプルに
[1,2,3].map(x => x * x);
// ES5 ではこう書く必要があった:
// [1,2,3].map(function (x) { return x * x; });

// n! (nの階乗) を求める関数もシンプルに
var factorial=((f=n=>n>1 ?n*f(n-1):1)=>(f))();
factorial(10); // 3628800

Arrow Functionには、簡潔に書けるということに加えて、もう一つ良いことがあります。それは、thisが保持・バインドされるということです。今まで、コールバック関数内で呼び出し元のオブジェクトを参照しようとすると、thisがwindowオブジェクトを参照するようになるため、コールバック関数の前で「self = this」などと記載し、この場合はコールバック関数内で「self」を参照しなければなりませんでした。Arrow Functionですと、Arrow Function内のthisが、その外側の関数のthisを参照し続けるという特性があり、このような記載が不要となります。

Generator

nextメソッドを持ち、繰り返し処理が実行される際にnextメソッドが呼ばれる特殊なオブジェクトをイテレータ(iterator)と呼びます。イテレータを簡単に生成できるジェネレータ関数によって生成されたイテレータをジェネレータ(generator)と呼びます。ジェネレータ関数では、yieldというキーワードがreturnの代わりに使われており、yieldが実行されるとその引数が返却されて関数の処理が一時停止します。そして、再度関数が実行されるとyieldの次の行から処理が再開し、またyieldが実行されると引数を返却して処理が一時停止する、という処理の流れになります。ジェネレータ関数を使うことで、関数の再起呼び出しを行うことなく、何かしらの繰り返しの処理を行うことができます。

// ジェネレータ関数 (ジェネレータのコンストラクタ)
function* fibonacci() {
  let [prev, curr] = [0, 1];
  for (;;) {
    [prev, curr] = [curr, prev + curr];
    yield curr; // 値を返して一時停止
  }
}
for (n of fibonacci()) {
  if (n > 20)
    break;
  console.log(n); // 順に 1, 2, 3, 5, 8, 13
}

先ほどのfor…ofの中でジェネレータ関数を使う方法以外にも、毎回明示的にイテレートする方法があります。こちらがイテレータの本来の使い方なのですが、例えば、カウンタを作成する場合、毎回一時停止して内部で保持している値をインクリメントするジェネレータ関数を定義すると、nextメソッドを呼ぶたびにインクリメントされた値を取得する処理を実装することができます。

function* counterGenerator() {
  let c = 0;
  for (;;) {
    yield c++; // 値を返して一時停止
  }
}
// ジェネレータを生成
let counter = counterGenerator();
// next() メソッドで {value, done} を得る
counter.next(); // -> {value: 0, done: false}
counter.next(); // -> {value: 1, done: false}
counter.next().value; // -> 2
counter.next().value; // -> 3

Promise

Promiseを使うことで、今までよりもコールバックを非常に簡潔に書けるようになります。また、catchなどの構文も今まで以上に書きやすくなります。Promiseを生成するときに引数として関数を渡し、そこでresolve関数とreject関数を指定します。このresolve関数が呼ばれたときにこのPromiseインスタンスが解決し、このインスタンスのthenメソッドが実行されます。

let p = new Promise(function (resolve, reject) {
  // 3 秒後に resolve 呼んでプロミスが解決する
  setTimeout(resolve, 3000);
});

// 解決した (resolve が呼ばれた) ときに実行:
p.then(function () {
  alert('3 秒たったよ!');
}).then(function () {
  // 解決済みなので即ここも実行される
  alert('既に 3 秒過ぎてるよ!');
});

p = new Promise(function (resolve, reject) {
  dream(); // 未定義の関数を呼ぶ (エラー発生)
});

// エラー発生時は then をスキップして catch へ
p.then(function (message) {
  // p は解決しないのでこのブロックは実行されない
  alert(message);
}).catch(function (error) {
  // p でエラーが発生するのでこのブロックを実行
  alert(error);
  // -> ReferenceError: dream is not defined
});

New Type & API

Collections

Set型、Map型が追加されます。Setを使うことで、集合に対して要素を追加したり参照したりすることができます。Mapは、キーとそれに対応する値を保持できるものです。配列やオブジェクトではキーとして文字列しか設定できませんでしたが、Mapではキーとしてオブジェクトを設定することができます。

var set = new Set();
// 集合に追加・確認・削除
set.add("Firefox");
set.add("Thunderbird");
set.add(+0);
set.add(NaN);
set.has("Firefox"); // -> true
set.has("Sunbird"); // -> false
set.delete("Firefox");
set.has("Firefox"); // -> false
// -0 と +0 は区別される, NaN は区別されない
set.has(-0); // -> false
set.has(NaN); // -> true

var map = new Map();
var str = "Mozilla", obj = {}, func = function(){};
// Map に値を格納
map.set(str, "Firefox");
map.set(obj, "Thunderbird");
map.set(func, "Japan");
// キーに対応する値を取得
map.get(str); // -> "Firefox"
map.get(obj); // -> "Thunderbird"
map.get(func); // -> "Japan"
// 設定したキーと引数の比較は == ではないので注意
map.get("Mozilla"); // -> "Firefox"
map.get({}); // -> undefined
map.get(function(){}) // -> undefined

ここまで次世代言語仕様の一部をご紹介してきましたが、このようにJavaScriptは構文や機能面でも大きな進化を遂げ、落とし穴が少なくシンプルな記法で書ける言語に進化するのです。
そして一方、広く使われる言語は書きやすいだけでなく高速でなければなりませんが、ここからは速度面の進化についてご紹介します。

Slow Parts & Fast Parts

JavaScriptが遅い原因として、JavaScriptが動的型付け言語であることや、JavaScriptにクラスと配列が存在しないことなどがありますが、これらの原因を回避して、JavaScriptエンジンが最適化しやすいコードだけを書くようにすることで、処理を高速化させることができます。例えば、型固定で変数を定義することや、一度定義したオブジェクトのプロパティの追加・削除を行わない、といったことなどに気をつければ、処理を高速化させることができます。このように、JavaScriptエンジンが最適化しやすく、高速化を図れるコードを、私の中で「JavaScript Fast Parts」と呼んでいます。

Typed Array

Fast Partsの代表的なものとして、Typed Arrayがあります。これを使うことで、今までJavaScriptではできなかった静的型付け・型の固定を行うことができます。

// 16 バイト長のバッファを確保
var buffer = new ArrayBuffer(16);
// 32bit 整数 x 4 として読み出すビューを定義
var int32View = new Int32Array(buffer);
// 32bit 整数として 0, 2, 4, 6 を格納
for (var i=0; i<int32View.length; i+ +) { int32View[i]=i*2; }
// 16bit 整数 x 8 として同じバッファを読み出すビュー
var int16View = new Int16Array(buffer); // 実際に読み出してみる
for (var i=0; i<int16View.length; i++) {
	console.log(int16View[i]);
}
// -> 0, 0, 2, 0, 4, 0, 6, 0

asm.js

以上のような高速化できる方法だけを使ってコードを書く、ということをあらかじめルールとして定めてしまい、JavaScriptエンジン側も最初から最適化された状態でコンパイルして高速に実行するようにしよう、という発想に基づいた高速化方法を、Mozillaがasm.jsとして提案しています。コードを自動生成するための様々なツールが存在していますが、これらは全て、JavaScriptエンジンが速く実行できるコードを生成しようとしています。このように、既存のエンジンにおける高速化のノウハウがある程度溜まっているため、それらのノウハウを結晶させたFast Partsを使って高速化を実現させるということが、asm.jsの発想です。

asm.jsの目的は、WebをNativeと同様の速度にすることです。Native同様の速度にするために、新しいコンパイルの方法を導入したりするわけではありません。現在のJavaScriptエンジンでも、最適化できるコードに関しては、既に型固定の高速なコードが生成されるようになっています。その際に、コード生成のためのオーバーヘッドや型変換時のチェックなどがあり、これらがなければNative並みの速度で実行されるようになりつつあります。このエンジンをそのまま利用して、今まで「このコードを最適化して良いか否か」をヒューリスティックに判別していたところを、asm.jsを利用すると、決め打ちで最適化できるようなります。

既存のJavaScriptエンジンでも、よく使われるコードを見つけて、それらを最適化することが幅広く行われています。しかし、簡単なコードは最適化できても、巨大なコードは最適化できない場合が多く、C言語よりも10倍、20倍遅い場合もあります。asm.jsを利用し、常に最適化するようにした場合は、asm.js導入直後の時点でもC言語の2倍の速度で済むレベルまで高速化されました。asm.jsでの高速化は、現在も改良が進められています。

結論：Always bet on JavaScript!

Webは非常に互換性を重視しており、既存のものを動作させ続けながら、機能を追加したり速度を改善したりする必要があります。本日ご説明しました通り、JavaScriptでは、必要な機能の追加や高速化が順次行われているため、JavaScriptはこれまで同様に生き続け、皆さんが勉強する価値のある言語になっていると思っており、これからもJavaScriptを愛して頂ければ嬉しいです。