asm.jsの評価(JVM,PNaClとの比較、および、現在の問題と今後の可能性について)

asm.jsに関する客観的意見があまりないようなので、ツイートをまとめてメモ。

現時点での機能はC/C++コードの移植に特化している

  • 文字列にもオブジェクトにも配列にもアクセスできない
    • JavaScriptの値で使えるのは数値だけ*1
    • typedarrayについては、同時に1つだけ*2アクセスできる
  • GCがない
    • オブジェクトにアクセスできないと書いたけど、当然newもできない
    • 自分でmalloc/freeから実装する必要がある
  • 関数ポインタすらない
    • 定義された関数呼び出しは可能

つまりは、フラットなデータメモリ、シンボルベースのコード空間と、数値演算機能のみがある、とても低レベルな仮想マシンということ。ネイティブコードをJavaScriptに変換した場合に高速に動く環境を作ろうとしていることは明らかだし、それ以外の目的では非常に使いにくい。

既存の他のアプローチ(JVM, PNaCl)と比較した場合には以下のようになる

  • JVM
    • asm.jsはJavaScript処理系で実行可能(JVMは独自)
    • asm.jsはメモリアクセス毎にガードコードの実行が必要(JVMJITコンパイル時のみの検証でいいのでより高速)
  • 対PNaCl
    • asm.jsはJavaScript処理系で実行可能(PNaClは独自)
    • ARM上で動作するPNaClはメモリアクセス毎にガードコード実行するという点で同様*3
      • ただ、未定義動作を許容するPNaClの方が高効率のはず

ただ、前述したとおり現状の asm.js は JavaScript の世界と細粒度でのやりとりがしづらいので、JavaScript処理系で実行できることが大きなメリットであるとは言い難い。JVMあるいはPNaClと比較して優位にあるとは言えないのではないか*4

将来性について

asm.js - frequently asked questionsES6 structured binary data APIへの対応を検討している旨が述べられており、今後、上記制限のうちオブジェクトの生成とアクセスについては対応するのかも。そうなると、なかなかに競争力のある選択肢となる可能性がある。

*1:と数値に変換されるundefined,null,boolean

*2:emscriptenでメモリ領域を表現するために使われる「heap」

*3:x86と違ってセグメントレジスタを使ったサンドボックスが作れないため

*4:その両者に現時点で競争力があるかはさておき