IGDA勉強会SIG-GT6「マルチコアプロセッサ時代のゲーム開発」に会社の同期のTと行ってきました。
http://www.igda.jp/modules/news/article.php?storyid=646
内容的には、IBMの有本さんの「Cell Broadband Engineプロセッサアーキテクチャ概要」と、ライターの後藤弘茂さんの「Cellプロセッサに期待すること」について。
まず、有本さんの発表だが、細かい部分（パイプラインの設計や分岐命令の系統など）ははっきりと覚えてないが、概要をざーと説明。詳しい部分は、
http://www.igda.jp/modules/news/article.php?storyid=664
ここに資料がまとまっているので、参考にしてください。特に、
http://www-128.ibm.com/developerworks/forums/dw_forum.jsp?forum=739&cat=46
を眺めるといろいろな情報が満載です。
とりあえず、Cellの概要からですが、Cellはgame/multimediaの処理を得意とするCPUで、ネットワークや外部命令からのリアルタイムな応答性に最適化して設計されている。現在Cell上で動作しているソフトウエアのほぼすべてがシミュレータを通して開発したので、安心してシミュレータを使って開発してほしいとのこと。Cellに関しての細かいことは、
http://www.research.ibm.com/journal/rd/494/kahle.html
に詳しい。
まず、知っての通り、Cellは命令を発行、マネージメントするPPEというPower系のCPUと、独自のベクトル、浮動小数点演算を得意とする命令セットを持った８個のSPEから構成されている。それぞれ、整数、浮動小数点、Vectorに対して別々のレジスタを所持するが、Cell自体はパイプラインをできるだけ少なく設計してあり、これだけの周波数（Cellは５GHｚで動作可能）で動作するCPUの中では、群を抜いてシンプルな設計になっている。PPE自体が２Wayのマルチスレッドが可能で、片方が片方をロックしながら、動作ができる。
SPEとPPEをつなぐEIB(Element Interconnect Bus)についてはかなり興味があった。結局、ここの設計が最終的な性能に対する大きなボトルネックになってくると感じていたからである。EIBの簡単な説明は以下に詳しい。
http://pc.watch.impress.co.jp/docs/2005/0208/kaigai153.htm
基本的に、EIBはCellのCPUの図を見てもわかるが、円を描くようにPPE、SPE８個、メインメモリ、I/O２個をつなげている。
http://www.research.ibm.com/journal/rd/494/kahle1.jpg
このEIBは反時計回りに２本、時計回りに２本のバスを通しており、256GByte/sec@４Ghｚというにわかには信じられない性能をたたき出す。もちろん、時計回り２本と反時計回り２本なので、頻繁にメモリ転送があると、簡単にコンフリクトする。そのようなときは、近い方からアクセス、通れないときは逆周りという簡単なプロトコルの挙動は従うらしいが、おそらく、この部分にコンパイラ、プログラミングの最適化が必要になってくると思う。つまり、ここの部分の最適化が進まないと、今後SPEの数を増やしても性能がでないことになる。
SPEに関しては、256KBのレジストリを所持し、主に浮動小数点演算と、double word（long longとか）のベクトル演算をサポートする。ただし、PPEと違い型毎のパイプラインはもっていないので、その部分で効率化を考える必要はない、シンプルな設計である。
肝心のIO/BIFも最大60GB/secの幅を持ち、IOの幅はフレキシブルに調節可能である。テストケースでは、BIFをつないで、８個のCellをマネージメントCPUでつないだテストマシンも作成したらしい。Cell２つのみでのDualモードもすでにサポートしている。
さて、ここからが、本題だが、Cellで性能をマックス出すためには、SPEをどのように使い切るかを考える必要がある。SPE自体が並列で挙動可能なSPUとDMAからなっており、SPUが計算している間にDMAがいかにデータを転送するかが性能をだすためには重要なため、計１８個の非同期の計算エンジンを使い切る設計が求められている。
PPEはSPEのコントローラとしての意味合いが強いが、SPEがSPEを操作することも可能である。テストケースでは、SPE１から６がレンダリングを行い、SPE7がそのデータを統合、SPE8がコーデックという作業をしていて、PPEが仕事の発行だけを行っていた。
現在、考えられている単純なプログラミングモデルは、関数という形で仕事を各SPEに割り振るFunction Offloadモデルであるが、もちろん、これだけで性能をだせるわけがないので、この部分に対する研究、自動化、最適化は今後も続けていく。IBMはこの部分のサポートでお金を稼ぎたい匂いをかんじたw。現在のプログラミングモデルはつまい、RPC-like（SOAP的と言ってもいい）なモデルである。
現在、Cell上で動作しているOSは64bit-Linuxで、メモリ管理、例外処理、スレッド処理、スケジューリングに関して拡張を行ったOSである。壊しいことは、SDKを参照。
http://www.ibm.com/developerworks/power/cell
簡単にApple G5 2.0GHzとの性能比較がのっていたが、簡単なレンダリング処理プログラムでは、4.0GHzのCellと比較しておよそ５０倍の性能差が出ていました。なお、レンダリングの稼働時間中、G5は40%の時間がメモリの転送待ちに費やされ、Cellは１％ほどだったもよう。
後藤宏茂氏の発表は、ほとんどImpress PC Watchの記事そのままだったので、そっちを参照してください。
http://pc.watch.impress.co.jp/docs/article/backno/kaigai.htm
とりあえず、重要なことは、Cellに接するためのパラダイムシフトの重要性を言っていました。特に、オブジェクト指向開発への移行の重要性を述べている。この部分は、オブジェクト指向というよりは、デザインパターンの話だと思う。つまり、効率的にCellを利用可能なプログラミングを書くためには、ノウハウをデザインパターンという形で共有する必要があるということ。これに関しては同感。
最後に、簡単なパネルディスカッションがあったが、現在Cellでゲーム開発を行っている人の意見が赤裸々でおもしろかった。いまのところ、PPEがメインのプログラミングを行っており、SPEはあまり使っていないらしい。というのも、PPE自体が3.2GHzのG5みたいなもので、ビデオカードもnVidiaの最新を搭載しているため、従来程度のゲームを作るためには、SPEは必要のないものらしい。なので、ツールライブラリーとワークフローが充実してきたらSPEも有効利用しようかなーくらいのことを考えているらしい。GPUとSPEのバランシングについても述べており、微妙に得意なことがかぶっているため、実際は、SPEプラスGPUのバランシングをトータルで考える必要があるとのことです。あと、SPEの利用に関しては、最適化を行わず、シビアなタイミングの転送を作らないことが重要だと述べていました。
細かいことは忘れたけど、基本はこんな感じかなー。勉強会で感じたことは、とにかく、いろいろな考え方のシフト、技術のシフトをCellが迫ってくるということ。そのことに関しては、明確に目的を意識してゲームを作る必要性を感じました。とりあえず、そんな感じです。
最近のRadium Software Developmentも、この手の話題が多いので、参考になるかと思います。
http://www.radiumsoftware.com/