Haskell の組み込み
ゲームプログラミング界の巨人、Tim Sweeneyが「未来のゲーム開発テクノロジー」を語る
Sweeney氏は純粋関数型言語のもつ並列処理安全性に着目しており、将来的にゲームプログラミングはそういった処理系に移行していくべきだとした。 Sweeney氏はそのひな形として言語“Haskel”を挙げているが、ゲーム開発のメインストリームたり得る言語はまだ登場しておらず、将来に期待しているという。
このときの Tim Sweeney 氏の話は、ゲームエンジン側のプログラマが超並列処理*1を記述可能な新言語へ移行しなければならないという話だった。同氏はハッキリ言い切らなかったが、ゲームプレイコード（組み込みスクリプト）は、ゲームの開発効率を保つために、既存の逐次処理ベースのスクリプト言語を使用し続けると考えていいだろう。
ゲーム以外の開発の分野もほとんどの業界でその方向を保つと思う。 .NET Framework のような VM 自体はメニーコアプロセッサーの都合に合わせた超並列プログラミングで開発されるが、その上でアプリケーションを書くプログラマは Ruby や C# といった人間優先プログラミングが可能な状態が維持されるんじゃないでしょうか。ある程度の並列は絶対求められるけど、Windows や Linux 上のプログラミングなら他にもプロセスやスレッドが走ってるだろうし。
が、実は先日の SIG-GT12 でこの真逆の話題が一瞬だけ出た。 Tim 氏の話はゲームエンジン側が超並列優先、ゲームプレイコード側が人間優先というスタイルだったけど、"その真逆"の話というのは、ゲームエンジンのほうを C/C++ で書いて、組み込みスクリプトとして Haskell を組み込み、 Haskell でゲームコードを実装するという涙目の構図。会場では一種のジョークとして受け止められていたのだが、 SIG-GT12 の汎用スクリプト言語の話が基本的に C/C++ プログラマが補助的に使用する（昔の C + アセンブリスタイルの）開発体制だったことを考えると、意外と検討の余地があるような気がしてきた。
仮に移行するなら移行期としてありだし、 C/C++ 部を並列処理コントローラくらいの立ち位置ととらえれば実用性もあるかもしれない。Haskell の並列処理を、組み込み時でも正しくスレッドに割り当てることができれば、 Cell のような特殊な（非対称型）マルチコアプロセッサーはともかく、 PC では面白い効果が測定できるような気がする。将来的な構図を考えると、超並列プログラミングと人間的プログラミングの将来的な役割分担の逆転状態を作ってみるというのは面白い。
また Tim 氏の言うとおり、まだしばらく C/C++ が使われるだろうし、
メニーコア時代のメイン言語も Haskell ではないと思う。しかし、今の時代に Haskell が効果的なのは間違いないから、シェーダ言語のようなドメイン特化言語として組み込んで積極的に生かすことで効果があげられるかもしれない。４コアだと微妙かもしれないが、１６コアくらいになってくれば……
PC ならフリータイムにテストができる。(*^▽^*)
２コア機しか持ってないけど。
ってかもう北米はやってんじゃないですかね。アンチャーテッドって schema 使ってたらしいじゃないですか。次回作で突撃済かもしれん。勝手にSPUじゃ無理とか決めつけたけど、ミニマムタスクを並列する方式では無理でも、SPUには1コアに1スレッドをドカンと振っちゃう方式もあるし。
と、こういうふうに思いついたことを試していけばいいんだよな……メモメモ。
いやしかし、もうね……
Sweeney氏はこれについて、従来的なクロック数の概念ではあまり変わらないものの、マルチコア、メニーコア化が進むことで、2020年までに現在の1,000倍のマルチスレッド及びベクタ処理性能が得られるという展望を示した。
1,000倍って、ファイバーレベルで100万本近いスレッドを走らすってことですよね。モゥプログラミングガソウゾウデキナイ……
「１０年後も技術者でいたい」
ってよく言うけど、１０年後も技術者でいるってそういうことなんだなと。この１０年は比較的予測できたし、フリーランチの終焉とかいう話が出るまでは、プログラミングそのものは楽になっていきました。しかしこの先１０年は……個人的には、開き直って楽しむしかないかなと。 )^o^(
とりあえずソース落としてきた……けど、いじれるのは４月くらいからだろうなぁ……
*1:ここではメニーコアに対応したプログラミングという意味で使用する
XCの並列処理への準備状況について
先ほどちらっと書いたけど、１コアの処理速度が頭打ちである以上、カーネルが持つスケジューラ上で振り分けの候補となるスレッドはスクリプトプログラミング上でもしっかり使って行くことになる。PHP6がスレッド処理を積まないという予想外の展開があったものの、XCは例のタスクシステムで並列処理に対応する予定で動いてきた。
しかし試しようがないので orz 、一部を Ruby にポートして理論をテストした。が、タスク並列は典型的な並列処理のひとつだから、そりゃ動くでしょ……っていう……
XCLと異なり、XCはタスクシステムで動くので、ブロックもモジュールも同階層で実行して、子タスクに移る前にJOINするというやり方でざっくりと並列化できる*1。またスレッド制限を設けて、兄弟の多いタスクの一人息子を、叔父のタスクと一緒に並列処理する方法が最終実装ですが、これの準備はやってません。このへんは今度図にします。
XOOPS のような構造のアプリは並列化がむちゃくちゃ効くと思う。なにしろモジュールは元々独立しているので、並列に向いている。順序依存の処理も、XCコアのタスクシステムように、親子構造に展開すれば保障できる。
もともと独立したモジュールを書く開発者が多いから、いくつかの（いつもの）決まりごとさえ守ってもらえれば、自動で並列化できますよとアナウンスできるのも大きい。付け加えると、RDMSがソフトウェアトランザクションを持ってるので、 Web アプリのコード側って、書き込み側も相当簡単にスレッドセーフにできる。
逆に言えば同じアプリ構造のプロジェクトは当然のように並列化を進めてくるでしょうね。それゆえに、PHP6がスレッドをサポートしなかったのは衝撃だった。
以前、どの言語を使用しても Web アプリケーションではアプリ自体の機能差がないと書いたけど、処理速度で大きく水を開けられる気が……*2
