どのブラウザでも動くウェブのバイトコードは価値があるだろうか。LLVMはソリューションとして成り立つだろうか。ネイティブコードをブラウザ上で動かすにはMozillaのasm.jsとGoogleのPNaClのどちらがいいだろうか。この記事ではこれらについての意見を紹介する。
ArsTechnicaのJavascriptで書かれた動画コーデックについての記事に対するRanizのコメントは同記事のコメント欄やウェブ上でさまざまな反響を起こした。Ranizは“ブラウザ向けバイトコードを標準化し、開発者がさまざまな言語を選択できる”ようにして、開発者がJavaScriptを使わざるを得ない状況を脱し、好きなウェブプログラミング言語を選択できるようにすることを提案している。そのバイトコードはJVMやCLRのバイトコードと同じように、ウェブ開発の共通プラットフォームになる。一見この考えは興味深い。LLVMのバイトコードを中間“バイトコード”として使うというアイディアもある。すでに、ActionScript、Ada、D、Fortran、Haskell、Javaバイトコード、Objective-C、 Python、Ruby、Rust、Scala、C#といったたくさんの言語向けにLLVMコンパイラが存在する
LLVMのバイトコードの問題はターゲットに依存することだ。つまり、異なるアーキテクチャ向けにバイトコードを生成するのが難しい。Javaとの大きな違いだ。Javaは異なるターゲット向けでも同一のバイトコードを生成する。JVMが動作環境を考慮してネイティブコードを生成してくれる。また、ユニバーサルなウェブのバイトコードを考えた場合、他にもいくつか問題があり、その中にはLLVMのバイトコードを悩ませている問題もある(詳しくはこちら)。msclrhd氏のコメントから抜粋すると、
バイトコード標準化の問題はJavaScriptの最適化を妨げることです…
各JavaScriptのエンジンは異なる文法を持つバイトコードセットを持っています。すべてのエンジンでバイトコードの使い方を統一しなければ、標準化できません。
エンジンごとの文字列の扱いの違いも考慮する必要があります(V8/ChromeはASCIIの文字列変数、MozillaはすべてUTF-16)。型についても同様です(例えば、Firefoxの"fatvals"は64ビットの値型で、32ビットを型に残りの32ビットを値に使っており、64ビットのdouble型はNaN値の表現を利用している…
バイトコードがバイナリなら、エンディアンの問題は浮動小数点の問題などもあります
MozillaでEmscriptenとasm.jsに携わる研究者のAlon Zakai氏はユニバーサルなウェブのバイトコードについてブログに書き、課題を概観している。
ひとつのバイトコードをほしがっている人もいれば、そうではない人もいて、理由もさまざまです。複数の言語がひとつのVMで動くことが好ましいという人もいます。しかし、いくつかのVMはプロプライエタリであり、特許があり、ひとつの企業によってしっかりと管理されています。このようなVMを嫌う人もいます。したがって、単一のユニバーサルなバイトコードの候補がないのです。理想的なバイトコードと可能性のある複数の候補を望んでいる状態です。
Zakai氏はユニバーサルなバイトコードの要件を一覧にしている。
- すべての言語をサポートする
- 動作が高速
- 便利なコンパイラターゲット
- 転送しやすいコンパクトな書式
- 標準化されていること
- プラットフォームに依存しない
- セキュアである
Zakai氏はこの要件を満たすユニバーサルなバイトコードについて具体的に語っていないが、JavaScriptがひとつの候補にあると考えている。“上の7つの要件から考えるとJavaScriptは既にバイトコードのVMが提供するものを提供できる状態に近い”。しかし、JavaScriptに足りないことについても書いている。
現時点で足りないのは、言語のサポートです。そして、性能に影響があるプラットフォーム上の制限があります。これは、特に、SIMDがないことや共有状態を持つスレッドがないことが制限を生んでいます。
JavaScriptはSIMDとイミュータブルメモリスレッドの欠如を埋めることができるでしょうか。時間が経てばわかるでしょうが、これには多くの労力を必要とします。はっきりしているのは、JavaScriptを標準化するのは新しいバイトコードを作成するよりも、シンプルで現実的だということです。新しいバイトコードを作るのは何の優位点もありません。
言語間の型の衝突、ガベッジコレクション問題などユニバーサルなVMを作ることの難点を説明して、Zakai氏は次のような結論を示している。
私はウェブ向けの新しいバイトコードを構想することは技術的にはあまり益がないと思います。唯一の明確な利点は新しいバイトコードを作ることがエレガントなソリューションであるということです。古いものを捨ててスクラッチからデザインできるからです。これは魅力的な考えです。一般的にはエレガンスは優れた結果を生みます。しかし、この特定のケースにはエレガンスから得られる技術的な大きな利点はないでしょう。エレガンスのためのエレガンスになってしまうのです。
ユニバーサルなバイトコードは成功する可能性は大きくないものの、ウェブの世界にプログラミング言語を持ち込もうとする大きな試みが最低でも2つある。両方ともC/C++から始めているが、他の言語にも展開しやすい試みだ。興味深いのは両方ともLLVMを使っていることだ。
- Mozilla: C/C++ –> LLVMバイトコード –> Emscripten –> asm.js –> ブラウザ
- Google: C/C++ –> LLVMバイトコード –> PNaCl –> ブラウザ
asm.jsはJavaScriptの一部を標準化する試みだ。すべてのブラウザで動作するようにし、JavaScriptエンジンのスピードをさらに最適化する機構が組み込まれている。EmscriptenはLLVMバイトコードからasm.jsを生成するプロジェクト。Zakai氏によれば、Firefox上でasm.js経由でC++コードを実行した場合、ネイティブコードの50%の速さで動作する。彼らは性能は今後も良くなると想定している。
Googleが最近発表したPNaClは、InfoQでも詳しく報じている。PNaClはブラウザのサンドボックス内でC/C++コードを、ネイティブコードより80-90%速く実行する。David Sehr氏によれば、まだ改善の余地があるそうだ。Mozillaのプロジェクトよりも性能は圧倒的に良いが、代償もある。PNaClは2年以上も開発が続いている。複数のアーキテクチャ上でエンディアンの問題や異なるポインタサイズの問題、異なる浮動小数点の問題などを対処するのが困難なのだ。Chromeを拡張してasm.jsの最適化を利用する方がシンプルな方法だ。しかし、asm.jsは遅すぎる可能性がある。yab**uzのコメントいよれば、
asm.jsを使うするつもりはありません。asm.jsをサポートしていないブラウザでは遅すぎます。Flash Playerよりも遅いです。
Brendan Eich氏が1995年に10日で作成した言語であるJavaScriptは、当初は静的なウェブページに動きを吹き込むために開発されたクライアントスクリプティング言語だった。この小さな言語の役割が20年後、さまざまな批判を受け欠点を指摘されながら、ここまで大きくなるとは誰も予想していなかっただろう。JavaScriptは現在、すべての主要なブラウザで活用され、Node.jsの人気も相まってサーバサイドでも利用され始めている。これはJavaScriptが素晴らしい言語だからではなく、メジャーなプレイヤーが協力してより良いソリューションを作り、ソフトウエア産業の歩みをスイッチさせるのが難しいからだ。HTTPやHTMLと同じように、欠点があり、もっと良い方法があると思われていながら、JavaScriptは普及を続けいている。
私たちは今、JavaScriptはべったりだ。ウェブのためユニバーサルなバイトコードを持つことがあるだろうか。必要なのだろうか。Mozillaの asm.jsやGoogleのPNaClのような試みは普及するだろうか。asm.jsとPNaClはどちらが優れているだろうか。