Haskell の組み込み

ゲームプログラミング界の巨人、Tim Sweeneyが「未来のゲーム開発テクノロジー」を語る
 Sweeney氏は純粋関数型言語のもつ並列処理安全性に着目しており、将来的にゲームプログラミングはそういった処理系に移行していくべきだとした。 Sweeney氏はそのひな形として言語“Haskel”を挙げているが、ゲーム開発のメインストリームたり得る言語はまだ登場しておらず、将来に期待しているという。

 このときの Tim Sweeney 氏の話は、ゲームエンジン側のプログラマが超並列処理*1を記述可能な新言語へ移行しなければならないという話だった。同氏はハッキリ言い切らなかったが、ゲームプレイコード(組み込みスクリプト)は、ゲームの開発効率を保つために、既存の逐次処理ベースのスクリプト言語を使用し続けると考えていいだろう。

 ゲーム以外の開発の分野もほとんどの業界でその方向を保つと思う。 .NET Framework のような VM 自体はメニーコアプロセッサーの都合に合わせた超並列プログラミングで開発されるが、その上でアプリケーションを書くプログラマRubyC# といった人間優先プログラミングが可能な状態が維持されるんじゃないでしょうか。ある程度の並列は絶対求められるけど、WindowsLinux 上のプログラミングなら他にもプロセスやスレッドが走ってるだろうし。

 が、実は先日の SIG-GT12 でこの真逆の話題が一瞬だけ出た。 Tim 氏の話はゲームエンジン側が超並列優先、ゲームプレイコード側が人間優先というスタイルだったけど、"その真逆"の話というのは、ゲームエンジンのほうを C/C++ で書いて、組み込みスクリプトとして Haskell を組み込み、 Haskell でゲームコードを実装するという涙目の構図。会場では一種のジョークとして受け止められていたのだが、 SIG-GT12 の汎用スクリプト言語の話が基本的に C/C++ プログラマが補助的に使用する(昔の C + アセンブリスタイルの)開発体制だったことを考えると、意外と検討の余地があるような気がしてきた。

 仮に移行するなら移行期としてありだし、 C/C++ 部を並列処理コントローラくらいの立ち位置ととらえれば実用性もあるかもしれない。Haskell の並列処理を、組み込み時でも正しくスレッドに割り当てることができれば、 Cell のような特殊な(非対称型)マルチコアプロセッサーはともかく、 PC では面白い効果が測定できるような気がする。将来的な構図を考えると、超並列プログラミングと人間的プログラミングの将来的な役割分担の逆転状態を作ってみるというのは面白い。

 また Tim 氏の言うとおり、まだしばらく C/C++ が使われるだろうし、
メニーコア時代のメイン言語も Haskell ではないと思う。しかし、今の時代に Haskell が効果的なのは間違いないから、シェーダ言語のようなドメイン特化言語として組み込んで積極的に生かすことで効果があげられるかもしれない。4コアだと微妙かもしれないが、16コアくらいになってくれば……

 PC ならフリータイムにテストができる。(*^▽^*)
 2コア機しか持ってないけど。

 ってかもう北米はやってんじゃないですかね。アンチャーテッドって schema 使ってたらしいじゃないですか。次回作で突撃済かもしれん。勝手にSPUじゃ無理とか決めつけたけど、ミニマムタスクを並列する方式では無理でも、SPUには1コアに1スレッドをドカンと振っちゃう方式もあるし。

 と、こういうふうに思いついたことを試していけばいいんだよな……メモメモ。

 いやしかし、もうね……

Sweeney氏はこれについて、従来的なクロック数の概念ではあまり変わらないものの、マルチコア、メニーコア化が進むことで、2020年までに現在の1,000倍のマルチスレッド及びベクタ処理性能が得られるという展望を示した。

 1,000倍って、ファイバーレベルで100万本近いスレッドを走らすってことですよね。モゥプログラミングガソウゾウデキナイ……

「10年後も技術者でいたい」
 ってよく言うけど、10年後も技術者でいるってそういうことなんだなと。この10年は比較的予測できたし、フリーランチの終焉とかいう話が出るまでは、プログラミングそのものは楽になっていきました。しかしこの先10年は……個人的には、開き直って楽しむしかないかなと。 )^o^(

 とりあえずソース落としてきた……けど、いじれるのは4月くらいからだろうなぁ……

*1:ここではメニーコアに対応したプログラミングという意味で使用する