Life is beautiful

　私の愛読書の日経エレクトロニクスに、Cell プロセッサのスケジューラに関する良い記事（７月４日号、Ｐ.１２３）が載っていたので、紹介する。次世代ゲーム端末向けのゲーム開発者は、ついに「日経エレ」にまで目を通さねばならない時代が来たようだ。とは言っても、ゲーム開発者に日経エレを定期購読してもらうというのも無理があるので、私が代理で目を光らせておき、読む価値のある記事を見つけたときだけここで紹介しようかと思う。

　ちなみに、この記事は東芝のエンジニアたちによって書かれた Guest Paper。ＣＥＬＬチップは、メインＣＰＵ（ＰＰＥ）１つ＋サブＣＰＵ（ＳＰＥ）８つ（ＰＳ３では歩留まりのために７つしか使わない）、という非対称な形のマルチ・コア・アーキテクチャを持つため、通常のＯＳのスケジューラーは使えない。そこで、ＯＳのスケジューラーとは別に、ＳＰＥ専用のスケジューラーを開発した、という開発者の立場から書かれたもので、私自身、ＯＳを開発して来た立場の者としては、とても興味深く読めた。ＣＥＬＬチップの上で、ミドルウェアなり、ローレベルのモジュールを開発しようとするエンジニアはぜひ目を通しておくべき記事だ。

　要点をまとめると、以下のようになる。

（１）ＰＰＥ（Power Processor Element）のスジェクーリングは通常のＯＳのスケジューラに行わせるが、８個あるＳＰＥ（Synergistic Processor Element）のスケジューリングは、ＰＰＥ上で走る「リアルタイム・リソース・スケジューラ」というモジュールが行う。つまり、ＰＰＥがマスターとなり、そのＳＰＥでどのＳＰＥスレッドを実行するかを制御するのだ。
（２）スケジューリング・アルゴリズムには、全てのＳＰＥを同じ周期（例えば映像の出力タイミングに合わせた33ms周期で）コンテキスト・スイッチさせる「ギャング・スケジューリング」方式を採用している。この方式を採用することにより、特定のリアルタイム制約（例えば、動画のあるフレームのデコードを次の出力タイミングまでに終えなければならないなど）に応じてSPEの割り当てを変更する、などのリアルタイム処理に必要とされる動的なスケジューリングが可能となる。
（３）ＳＰＥスレッドのスケジューリングは、プログラムからＡＰＩを呼び出して動的にコントロールするのではなく、ＸＭＬファイルで記述されたメタ・データにより行う。プログラマーは、そのメタ・データ内に、データの処理の順番（例えば、データ・マルチプレクサでビデオと音声データに分けた後、それぞれをビデオ・デコーダ、オーディオ・デコーダに渡すなど）や、リアルタイム制約などを記述するだけで良く、実行時のＳＰＥの割り当ては「リアルタイム・リソース・スケジューラ」が自動的に行ってくれる。

　これで、今まで疑問だったＳＰＥのスケジューリング方式がかなり明らかになった。ただし、このペーパーからだけでは理解できなかったのが、ＳＰＥのコンテキスト・スイッチの効率である。ＰＰＥとＳＰＥは共有メモリーを持たない構造であるため、ＳＰＥのコンテキスト・スイッチのたびに、ＳＰＥのローカル・メモリ全て（２５６キロバイト）を主記憶との間でＤＭＡ転送しなければならないのだ。これを最悪の場合で８つのＳＰＥに関して 32ms ごとに同時に行って、オーバーヘッドがどのくらいになるのかが気になってしかたがないのだが、このペーパーには答えを見つけられなかった。このペーパーには、マルチ・ストリームのテストプログラムを走らせたところ、平均して（32ms ごとに）1ms のオーバーヘッドで済むことが分かったと書いてあるが、それは４８本のＭＰＥＧストリームを同時にデコードする、という比較的単純なケースの実験結果なので、あまりコンテキスト・スイッチが起こらなかった故のオーバーヘッドの低さとも思えるので何とも言えない。

　商業的にＣＥＬＬチップなりＰＳ３が成功するかどうかはまだ不明だが、少なくとも「エンジニアのおもちゃ箱」としてはとても魅力的なハードウェア・アーキテクチャである。このペーパーを書いた東芝のエンジニア達も、やりがいのある仕事を与えられて楽しかったに違いない。ハードウェアで冒険はせずに、開発環境とオンライン・サービス環境で差別化を図ろうとするマイクロソフトと、ハードウェアとソフトウェアの両方で大きな革新を起こそうとするソニーとの違いは、その設計の根本思想からして大きく違う。極端な言い方をすれば、これは「米国のＭＢＡたちがビジネスで勝つためにエンジニアに作らせたXbox 360」と、「日本のエンジニアがエンジニアのために作ったPS3」との戦いである。目が離せない。

[追気] ちなみに、先日運転しながらラジオで芸能ニュースを聞いていると、突然 "multi-thread" という言葉が飛び込んできたので驚いた。映像業界では、「２４」のように、同時に進行する事件をシーンを頻繁に切り替えながら視聴者に見せる手法を「multi-thread 方式」と呼ぶらしい。ひょっとすると、こっちの方が古い用法なのかも知れない。エンジニア以外の人にマルチ・スレッドを説明する時に使えそうだが、そんな機会がそもそもあるかどうかが疑問だ（注意：理科系の学生は、合コンの時に決してマルチ・スレッドの話題はしないように）。