プログラミング言語なんてもう要らない

# 以前UIで同じキャンペーンをした気がする

C言語拡張がなぜ必要か

GPGPUにはいくつかの言語が登場している。

CUDA
Brook+ (+ AMD CAL)
OpenCL

このうちCUDAだけがC言語拡張として有名な気がするが、もちろん、残りの陣営もC言語の拡張となっている。
これらのコンパイラは、C言語の既存のコード、たとえばlibavcodecのようなソフトウェア(プロトコル実装)をそのままコンパイルしたからと言って、計算環境の機能を生かすようにはならない。
要するに、これらの言語がC言語風の言語たる所以は、TeX形式やXMLで数式を書くよりは、使い慣れた制御構文も使えるし楽だったからという理由でしかない。
既存のC言語プログラムには殆ど貢献しない。数少ない貢献は、C言語環境と統合されたAPIが存在すること位だろう。

プロセッシングの全てが記号処理ではない

新しい抽象化の必要性としては、個人的にはプロトコル記述言語としての必要性を主張しているけど、なかなか情勢は厳しいので別の意見。

http://morihyphen.hp.infoseek.co.jp/log2/200809.html#091514 - 『プログラミング言語は実行時の速度を中心にして設計されるべき』

例えば型システムとかGC、オブジェクト指向機能のようなものは記号処理の発想で、実際の演算を行う際には(ハードウェアはそれを処理しないから)単に不要な物だとしか言いようがない。
平たく言えば、コンパイラをうまく記述できる言語が、演算までうまく記述できる必然性も必要性も無い。
LLVMは悪くないアイデアで、そのような記号処理を言語フロントエンドで処理してしまって、残り(中間言語の処理)を実行することに集中すれば良い事になる。
しかし、LLVMの中間言語はこの手の処理(要するに行列演算やビット処理)に必要なプリミティブを欠いているため、そのままで現実的な演算処理に使うのは好ましくない。結局CUDAとかOpenCLの出番となってしまう。
OpenCLは当初LLVMのclangで実装されていると言われているが、仮にAMDとかnVidiaがOpenCLを実装するとしても、LLVMによる実装を流用できるかというと微妙な問題だろう。

http://www.watch.impress.co.jp/game/docs/20080911/epic.htm - 『生産性は必須』

この生産性がどこに掛かっているのかは注意する必要がある。
ここで言うところの生産性はゲームを構成するシステム全体の問題であって、何も演算までを純粋関数言語で書けという意味ではない。
実際の演算の手前までを純粋関数言語で書くことは悪いことでは無いと言える。実際twitterブームで一瞬Erlangブームが来たが( http://www.atmarkit.co.jp/news/200704/27/erlang.html )ネットワークで直面しているC10K問題は、そのまま、network is the computerの精神で*1コンピュータの筐体内でも発生する。
しかし、演算ハードウェアは純粋関数の世界ではなく、物理的な半導体の世界で動作している。

何が必要なのか

記号処理システムとしてのLLVMと言語フロントエンド

これはJavaや.netでも良く、誰がどれだけ投資するかという問題でしかない。
タイトルに反して、この部分だけはプログラミング言語を必要とする。

演算資源を抽象化するための中間言語

例えば、TGSI( http://www.tungstengraphics.com/wiki/index.php/TGSI )のような、シェーダのバイナリ表現は候補になるかも知れない。
SIMDと数値のバイナリ表現に良く対応する必要が有る。
CUDAとか既存のシェーダ言語のような形を採らないのは、言語に対して付けられた加工/分析用のAPIが成功した試しがないため*2。

DirectX→OpenGL トランスレータと、良いOpenGL実装

Wineを使えば良い。
要するに、今日のビデオカードを簡単に代替するためのソフトウェア環境を整備する必要がある。システムの投入当初から多数のアプリケーションが存在することが重要。

検討すべき課題

エントロピ符号化などの処理抽象化

現在、ビデオカードによるMPEG再生支援は基本的にビットストリームの処理をハードウェアで実装している。これをまたソフトウェアのプログラマブルな世界に戻すためには、この部分も良い抽象化が必要となる。
言い方を変えれば、データ構造処理のための抽象化レイヤを考えることで、これは今後DB方面や他の目的のために転用できるかも知れない。
個人的には、プロトコル記述言語でgzipやMPEG2をサポートするための言語機能として研究している。プロセッサやアーキテクチャを評価する上で評価尺度として用いることができるかもしれない。

コンパイラ/エミュレータの実現

コンパイラやエミュレータの負荷は現在ではほぼ無視されているが、どこかのタイミングで検討する必要が生じるだろう。
例えば、DirectX→OpenGLへのトランスレーションを、単なるAPIの移植ではなく(パフォーマンスのために)バイナリ変換によって行う必要が生じるかも知れない。
この部分に必要なコンピューティングリソースはあまり検討されていないように思える。手続き型言語で行われるような記号的な最適化ではなく、例えばビット検索命令を備えるのが実は有効であったといった事が存在するかも知れない。
Cellや近年のIA32など多くのプロセッサはビット操作/加工命令をかなり高度な処理まで備えているが、これが本来の利用目的以外に活用されている事例はあまり見かけない*3。