現在ではモバイルデバイスでさえ、並列処理能力を使えるのにJavaScriptは、シーケンシャルのままであった。 Intel Labsは、マルチコアシステムの利点を活かすJavaScriptの拡張に取り組んで、Firefoxプラグインをリリースした。
コードネームが River Trailという、JavaScriptの並列拡張は、Intel Labsのプロジェクトであり、IntelのマルチコアCPUの処理能力とそれらのベクター拡張をwebアプリケーションに持ち込もうとしている。 River Trailは、ブラウザー内でフォト編集のようなもっと数値計算が多いアプリケーションを動かせるようにしようとしている。
River Trailは、JavaScriptを拡張して、決定論的なデータ－並列の構成要素を実行時に、低レベルなハードウェア抽象層へ翻訳する。マルチCPUコアとベクター命令を利用して、 River TrailはシーケンシャルなJavaScriptに対して、著しい高速化を達成した、と言っている。
特に、それはJavaScriptに ParallelArrayデータ型を追加した。これは、実際の Parallel Array（並行配列）データを持つリードオンリーのデータ構造体である。Parallel ArrayはJavaScriptの配列、型付きの配列から生成できるし、 ParallelArrayの値を生成する関数を使うこともできる。例えば“new ParallelArray([1,2,3])”は、値1,2,3を持つParallelArray を生成する。その結果は ParallelArrayで、その内容は、データに並列にアクセスするcombine, filter, map, reduce などのような関数でアクセスできる。提供されるJavaScript関数は、OpenCLにコンパイルされる。これらの関数はJavaScriptのサブセットを使うことができる。
InfoQは、この開発について Intel Labsの Stephan Herhut氏に独占インタビューした。
InfoQ: River Trail プロジェクトの動機は何ですか？
Stephan: プロジェクトが始まったときには、私はIntelにいませんでした。なので本当の最初から開発に携わっている Rick Hudson氏にどうやって始まったのか聞きました
「マルチコア、多数のコアそしてベクター命令を持つマシン用にプログラミングすることをもっと簡単にして、生産性を求めるプログラマ、特にJavaScriptで開発しているwebアプリケーションプログラマに使わせたい、と言う考えが動機でした。高パフォーマンスで、かつ高生産性の構成物をwebアプリケーションプログラマに提供することは、難しい問題であり、それが我々をやる気にした側面の1つでした。」
私は今年の始めにプロジェクトに加わり、River Trailの開発で本当に興奮させられるのは、HTML5の文脈によく合うことです。ネイティブのアプリケーションと比べて、webアプリケーションを制限する多くの問題にHTML5は取り組んでいます。しかし、パフォーマンスとなるとまだ大きな差があります。ブラウザーベンダーはJavaScriptエンジンを高速化するのに素晴らしい仕事をしてきました。ネイティブのJavaScriptでbroadway h.264 デコーダーのようなものを見ると本当に感心します。しかし、JavaScriptはまだほとんどがシーケンシャルです。webプログラムはバックグラウンドでの長い待ち時間のある演算を許しますが、並列計算には余りに重すぎます。 River Trailはこの穴をデータ－並列演算で埋めます。GitHubにあるプロトタイプは、それが実行可能なアプローチであることを示しています。
InfoQ: 単に OpenCLコードを書くのに比べて入力言語としてJavaScriptを使う主な利点は何ですか？
Stephan: この質問には2つの観点があります。web開発者にとって何が利点か、そしてJavaScriptエンジン、最終的にブラウザーの開発者にとって何が利点かということです。
web開発者にとっては、一番の利点は使うのが簡単なことだ、と思います。新しい言語を覚える必要がありません。よく知っているプログラミング環境に留まることができます。 RiverTrailは、既存のJavaScriptの概念、例えば、配列、 map と reduceのような関数、関数引数として渡せるクロージャなどの上に作られています。実際、 RiverTrailには新しい言語構成要素はありません。また多くの場合、web開発者は、RiverTrailを使えば、自分のコードを直接再利用できます。forループを mapのようなRiverTrailのプリミティブに置き換えなければなりませんが、そのぐらいです。実際の仕事量をこなすのは、普通と変わりません。少なくともそれが狙いです。現在のプロトタイプは制限があり、ここまで到達してませんが、必ず到達する自信があります。この質問の他の面は、エンジン開発者にとっての利点は何かです。第一の利点はセキュリティに関する安全性です。webブラウザーは一番の攻撃表面です。ユーザーは、使っているブラウザーが安全なweb体験の保証を期待しています。 OpenCLはクライアント側のアプリケーションで使うように設計されており、一般には、ユーザーが信用できるソースからインストールします。OpenCLは基本的にCの方言で、そのすべてのパワーと危険性を合わせ持ってます。しかしJavaScriptは一般にはコードが信用できないwebで使われるように開発されました。我々はこの設計思想に従います。 RiverTrailは、例えば配列境界チェックのようなシーケンシャルな実行に使われるのと同じ安全メカニズムを使います。
別の問題は、可用性です。webアプリケーションは様々なプラットフォームやデバイス、ラップトップから携帯電話まで、の上で走ります。これら全てのプラットフォームの上で、JavaScriptはすでにありますが、 OpenCLはそうではないでしょう。ブラウザーのJavaScriptエンジンでのRiverTrail のネイティブな実装は、RiverTrail コードを直接ベクター化されたマシンコードに翻訳されます。完全にシーケンシャルな実行でも問題有りません。故意にAPI設計は、汎用的で多くの異なる実装を考慮しています。
InfoQ: Javascriptのシンタックスで表現できないOpenCLコードがありますか？JavaScriptにおける型アノテーションの不足が問題ではありませんか？
Stephan: RiverTrailは、web向けのOpenCLであるようには設計されていません。我々は、たまたまプロトタイプでのバックエンド技術としてOpenCLを使っています。RiverTrailはずっと高レベルの抽象を使っています。その結果として、ローカルな共有メモリー、同期バリアやワークグループのような、より低レベルなOpenCLのフィーチャはサポートしません。これらは、RiverTrailのような高レベルのAPIには、余りにOpenCL特有です。型は、我々が予想したほど問題にはならなかったです。まず、WebGL用に導入された型付き配列は、すでにJavaScriptで、データのストレージレイアウトを操るツールとしてプログラマーに与えられていました。我々はある程度、RiverTrailのプロトタイプですでにそれを使いました。次に、JITエンジンが値を表現する際の最適化で改善されました。JavaScriptの型推論で素晴らしい改善があり、その計算のパフォーマンスが非常に良いです。そしてRiverTrailはその改善から自動的に恩恵を享受しています。
InfoQ: ある所でWebCLと一緒にRiverTrailを使うことができるようになりますか？その場合、JavaScriptバージョンは可能でしょうか？すなわち、ネイティブなOpenCLライブラリ必要がないですか？別の考えとしては、 WebCL と WebGLを組み合わせるのはどうですか？RiverTrailはCanvasからビットマップデータを取ることができるようですが、OpenCLのメモリーから／へそれをコピーしているようですが。 WebGL と WebCLを組み合わせるとWebGLデータを取得し、それをWebCLで処理し（RiverTrailを使って生成されたカーネルと一緒に）、ブラウザーのメモリーへコピーバックせずに、WebGLへ戻すことができるでしょう。
Stephan: 我々がFirefoxの拡張を実装する決定を下したのは、純粋に歴史的な理由です。我々がRiverTrailの開発を始めたときには、WebCLはありませんでした。それが使える頃までには、我々は既に我々のインターフェースを実装してました。そのインターフェースは、WebCLの機能が簡単化され、減らされたバージョンです。GitHubにはRiverTrailの別バージョンがあり、我々のFirefox拡張ではなく、バックエンド実装としてWebCLを使っています。それが WebCL とwebGL間のバッファ共有をサポートしているかどうかは、わかりません。私が現在一番注力しているのは、web開発者から学んで、いかに上手くRiverTrailを彼らのニーズに合わせるか、そして彼らからのフィードバックを基にAPIを進化させることです。WebCLベースのバージョンを作成する人は誰でも歓迎し、サポートします。そのようなアプローチがどのような最適化の可能性を提供できるか確認することは、興味のあることでしょう。
InfoQ: 現在サポートしているJavaScript言語の構成要素にはどのようなものがありますか？もっと追加する計画がありますか？
Stephan: GitHubにある我々のプロトタイプは、概念の証しであり、我々が言語フィーチャで実験している場所です。現在プリミティブなデータの配列しかサポートしていません。我々はネストした配列をサポートしていますが、定形の場合だけです。例えば、我々は canvasからのイメージデータを4つの要素ベクターから成るマトリックスとしてモデル化します。他の制限としては、カーネル内のグローバル値や関数コールへの参照をサポートしません。これらの制限のほとんどは、我々のプロトタイプがJavaScriptエンジン内で実装されているわけではないことから来ています。このアプローチのお陰で、短時間でフィーチャをプロトタイプ化できますが、エンジンの内部情報へのアクセスは制限されます。 SpiderMonkey用の開発も進んでおり、もっと内部をスクリプトレベルからアクセスできるようになります。これがリリースされれば、もっと制限を取り除けるかチェックします。しかし、結局のところ、RiverTrailは直接JavaScriptエンジンの一部であるべきです。
InfoQ: OpenCL言語の目標がどのように、サポートしているJavaScriptのフィーチャを制限しますか？
Stephan: 主な制限は、ヒープ管理です。OpenCLでは、カーネル内で我々がアクセスしたいJavaScriptのヒープ部分を明示的にOpenCLヒープにマップする必要があります。このことが我々が現在なぜ気の利かないプリミティブな型の配列しかサポートできない理由の1つです。ネストした配列や任意のオブジェクトの配列を完全にサポートするには、基本的なデータ構造に対する完全なアクセスと潜在的なコピーができる必要があります。これは実現不可能で、CPU上で実行するには不要でしょう。
InfoQ: 数値に関して、JavaScript ASTでは、全ての数をdoubleとして扱いますか？doubleと整数とで違いがありますか？（すなわち、 'x = 42' は整数に変換されますか）
Stephan: JavaScriptのセマンティクスでは、全ての計算は64ビット浮動小数点で実行されなければなりません。そのような精度を必要としないことがしばしばあり、RiverTrailではweb開発者がカーネル実行中は、32ビット浮動小数点を使うように指定できます。更に、我々は範囲分析を実装しており、整数で計算するのが安全かどうか推論します。これは普通、ループ境界の場合に起きます。あなたの例では、 'x = 42'によってxが整数として保存されることになります。ただし、もしxへのその後の書き込みが32ビット整数値の範囲内であることを、コンパイラーが確認できた場合です。もしこのことが統計的に示せなければ、xは float か doubleで保存されます。
InfoQ: ParallelArrayが現在RiverTrailが提供する主要な抽象です。他の抽象のアイデア、あるいは全てのタスクがParallelArrayにマップできるのですか？
Stephan: ParallelArray抽象は、データ－並列な計算に上手く合います。並列プログラミングで他に面白いドメインは、タスク－並列な計算負荷です。分割と統治式のアルゴリズムがこのドメインに属します。web開発者は少々その方向に行きがちですが、そのアルゴリズム余りに重量級なため、共有された状態を許しません。私には未だ答えが無いのですが、タスク並列化は、検討に値する分野です。
InfoQ web開発者がGPUやマルチCPUコアを活用できるようになってくると、近い将来webアプリどう進化すると思いますか？
Stephan: 私自身はwebアプリの開発者ではありませんが、彼らの創造性には大いに敬意を払っています。WebGLの Chrome と Mozillaのデモが出てきた時は、私は畏敬の念をいだいて、ラップトップの前に座っていました。なのでどうなっていくのかを予言するのは非常に難しいです。webアプリは能力の点ではもっとネイティブアプリに近くなるでしょう。さもないと全然違ったものになってしまうでしょう。webアプリの大きな利点は接続性にあります。様々なデータソースを利用して、色んなものを混ぜあわせて、生情報を加え、見事なビジュアルデバイスを使ってそのすべてを表現できます。私はwebがもっと没入型になり、ページ中心のwebは徐々に少なくなる、と思ってます。ただ1つ確かだと思うのは、開発者が考えつくものに、私は驚き、仰天するだろう、ということです。
InfoQ:プロジェクトの将来のロードマップを教えて下さい。
Stephan: 我々はプロトタイプの制限を取り除くことに取り組んでおり、完全にJavaScriptをサポートに向かってどれだけ前進できるか検討しているところです。その一部がRiverTrailをJavaScriptエンジンに直接埋め込むことです。我々はMozillaと協働して、次世代のJavaScriptエンジンにRiverTrailをネイティブに組み込もうとしており、もっとブラウザーエンジンに入り込むための、いかなる助けも歓迎します。別の本当に重要なことはユーザーからのフィードバックです。最終的に、我々はRiverTrailがオープンな標準として、JavaScriptの一部になることです。しかし、それがweb開発者のニーズと彼らの使用性に対する懸念を解決することを確認したい、と思っています。これについては、webコミュニテイ次第です。RiverTrailを試し、それで新しいものを作り、体験を我々に話して欲しいです。