jetpack-to-CUDA - w

http://journal.mycom.co.jp/news/2010/01/27/026/index.html

JavaScriptとかと比べると、CUDAのプログラムは150倍くらい速いのだが、それと同様に、SSEとかを使ったCPUコードはJavaScriptの100倍くらい速い点を考えると、まあ、そもそもCUDAは必要なのか？という気が。例えばバックエンドがCtという実装も十分ありなんでは？(訳注:150倍とか100倍とかの数字は妄想)

昔妄想していたネタと近いので、なんとなく思考を垂れ流しておくと…

なぜSSEではなくてCUDAなのか？というのは、安全性の検証の容易さと、実行の自由度のバランス的に、CUDAにしてあると何故かよくわからないけど説得力が出てきてしまう、というのが重要なんだと思う。

尚、以下の文は、GPUはCPUの1.5倍くらい速い、という前提で書いてます。GPUはCPUの100倍速いとかいうのだとアレですね。アレ。

まず、一番の前提条件は、「JavaScriptは安全ではないコードを実行できない」という点。
ブラウザの中で、ネイティブコードやフル実装のCUDA Cを動かすのは無理だと思う。CUDAはメモリ独立してるから大丈夫という気がするが、アレはメモリ破壊したりするとドライバが不安定になるというアレである。
これは、RubyとかPythonとかだと無くて、PyCUDAはフル実装のCUDA Cが動かせる。とは言っても、LLの人とかはメモリ破壊とか嫌いだと思うので、半分くらいはあてはまるかもしれない。

さて、この前提条件を守るには、実行時にチェックする仕組みを入れるか、静的に検証する仕組みを入れるしかない。フル実装のJavaScriptを静的に検証するのは難しいので、JavaScriptだけだと、実行時にチェックするしかない。

ここで、以下のような表記でプログラムが書けるとする。

var sqrFun = function(v) { return  v * v; }
map(sqrFun, numbers);

んで、map関数中で実行されるのは、ループを書かないとかの制限付きJavaScriptというような感じのものにしておけば、静的に解析するのは可能だろう。(どういう制限にしたらいいかは知らない)
こうすれば、実行時のチェック無しに、プログラムを動作させることができる。(あと依存性の解析をしなくてよいので並列化もしやすい)

このような表記を持ち出したときに、重要なことは、GPUで動く/動かない、ではなくて、静的に検証できるか/できないか、という点である。
静的な検証ができれば、高速なx86をバックエンドにして実行するというのも有意義なはずだ。

さて、この時、JavaScriptの関数には制限が加わっているのだが、この制限が理不尽ではないようにするにはどうすればよいだろうか。

バックエンドがx86の場合だと、少しでも制限が付いてしまった場合、「検証器の実装がショボいからだろwww」とかなってしまいがちである。
ところが、バックエンドがCUDAの場合だと、「CUDAで高速に実行するには並列化する必要があります。並列化はプログラマの責任です」とか言って、理不尽をプログラマのチャレンジに置換してしまうことができる。

つまり、「静的な検証器の実装のショボさをうやむやにするために、CUDAにしてある」、というわけである。

また、NVIDIAが「CUDAはCPUの百倍速い。これからはGPUの時代だ」と何年も主張しているというのが重要であり、よーするに「何を売るか」ではなくて「どうやって売るか」が重要だという話である。