[an error occurred while processing the directive]

Spring Processor Forum 2005レポート
~組み込みプロセッサとしてのCell

カンファレンス会期:5月17日~18日(現地時間)

会場:米カリフォルニア州サンノゼ
DoubleTree Hotel



IBM Fellow, IBM Systems and Technology GroupのJim Kahle氏

 今回のSPFではセッション4の“Advances in DSP Engines”の最後で、Special PresentationとしてIBM FellowのJim Kahle氏による、Cellに関するプレゼンテーションが行なわれた。これのみ事前資料配布もなければ、後で配布されたCD-ROMにもプレゼンテーションが入っていないため、開場で撮影した写真がベースになっており、やや見にくいことを最初にお詫びしておく。

 さて、Cellプロセッサそのものについては、既に後藤氏のレポートが数多く上がっており、かつE3でも色々発表があったため、重複は最小限に抑えたいと思う。

 ハードウェアから見れば、CellとはPowerPC 970ベースの汎用CPUコア(これをIBMではPPE:Power Processor Elementと呼ぶ)とは別に8個の独自プロセッサコア(これをIBMではSPE:Synergistic Processor Element)を搭載、間を高速なバス(EIB:Element Interconnect Bus)で接続し、更にメモリインターフェイスとしてXDR DRAMを2ch接続するMIC(Memory Interface Controller)とI/OインターフェイスとしてBIC(Non-Coherent I/O interface)を搭載したSoC(System on Chip)である。

 ではこのSPEとは何ぞや? という話だが、これに関しては相変わらず雲を掴むような話が列挙されているだけで、今ひとつはっきりと見えてこない。ただ、Kahle氏の話を聞くうちにわかってきたことがいくつかあるので、まずは簡単に流れを追ってご紹介する。

Cellの内部構造 “Cellとは何ぞや?”という問いに対する答えだが、Multi-Coreなどはともかく、その下になるとだんだん禅問答めいてくる

●組み込み分野から見たCell

 最初は、チップとしてのCellの話について解説。チップレイアウトを示しながら各ブロックが紹介され、次にCellを組み合わせたシステム例が提示された。

PPEが左端に用意される。大体半分近くが512KBのL2キャッシュ SPEは間にEIBを挟み、4列×2段で構成される。128bitのRegister Fileを128個と、更に256KBのLS(Local Store)を装備する Cellを使った1P/2P/4Pシステム例。これだけ見ると、多数のCellを接続するにはちょっとI/Oの帯域が少ない気がする。もっともこれは使い方次第なのだろうが、XDR DRAMを使う関係上、例えばShared Memoryを使ってのプロセッサ間通信が不可能だから、Flex I/Oを使った通信しかありえない。大規模システムではここのボトルネックが問題になるかもしれない

 さて、ここからがちょっと面白い話である。CellのMemory Mapによると、PPEとSPEはメモリを共有しない。メモリ空間自体は共有「できる」が、TLBやMFC RegisterはDMAによって共有エリアと高速に通信できるのに対し、各SPEのLSにはそうした仕組みが備えられていないように見える。

 ここで各SPEのLS間は、DMAを使って高速にメモリ転送が出来る。また、PPEのL2キャッシュからSPEのLSへもDMA転送が可能だ。ところが、LSからL2キャッシュに戻す、あるいはLSからメモリに戻すというスキームは用意されておらず(*1)、むしろLSからBIF/IOIF経由で出力する方が高速そうだ。

 (*1)後藤氏の記事によれば、LSからEIBへのDMA Writeが可能ということになっている。これが事実ならメモリあるいはL2キャッシュへのDMA転送も可能なはずだが、まだこのあたりは謎が多い。

MMUは、各SPEのLSをメモリ空間のどこにマップするかをダイナミックに変更できる様にするためだろう PPEとSPEの間の通信にMailBoxが入っているあたりも、これは普通のマルチプロセッサ構成ではないことがうかがい知れる

 こうなると、Cellをマルチプロセッサという扱いで考えるのはちょっと間違っているのではないか? という気がしてくる。いや確かにヘテロジニアスマルチプロセッサであることには間違いがない。ただ、「異なる種類のプロセッサで構成されていればヘテロジニアスマルチプロセッサだ」というのは嘘ではないのだが、それはあまりに広義すぎる。

 例えばIntelのx86シリーズの場合、386まではFPUを別に用意して接続したから間違いなくヘテロジニアスマルチプロセッサなのだが、普通はシングルプロセッサとして扱う。あるいはそもそもIBM PC自体が複数のプロセッサ(何しろキーボードにすら8bitのマイクロコントローラが入っていた)で構成されていたから、厳密に言えばヘテロジニアスマルチプロセッサシステムだが、これをマルチプロセッサシステムと呼ぶ人はあまりいない。

 キーボードコントローラの8051を別にすると、例えばIntel 387はコプロセッサという方が適当だと思うからだ。このあたり、明確に両者を区別する定義というのは(筆者が知る限り)存在しないが、CellのSPEは、ヘテロジニアスマルチプロセッサというよりもコプロセッサの扱いが近いと思う。もっと正確に言えば、SPEというのはプロセッサというよりも、DSPとして扱うほうがはるかに自然である。

 実際、SPEの特徴を見ると限りなくDSPに近い。処理の並列度を高め、データのスループットをひたすら上げる方向にアーキテクチャは設計され、制御構造などに対応した作りにはなっていない。コンテキストスイッチングも原則としては無しで、各々のSPEは自分に与えられた処理をひたすらこなし、終わったら再度新しい処理を(PPEから)割り当てられて再び実行という形になっている。これはどうみてもDSPである。

 更にSPE同士は相互にDMA転送を行なう上、キャッシュ間の同期をハードウェアで取ることで、高度に連携をしやすくなっているのに対し、SPEとPPEの間は(仮にDMA転送が可能としても)同期に利用できるのがMailboxという、プログラミングは容易だが決して高速な通信は出来ないメソッドしか無いあたり、PPEから見るとSPEはコプロセッサというか、Offload Engineという扱いになっていることが明白で、ここからもマルチプロセッサと呼ぶのは正直憚られる。

 SPFではCellは“プロセッサ+DSP”という括りで扱われていた。そもそもセッション4は名前の通りプロセッサ+DSP製品をメインとしており、ARMの「OptimoDE」をベースとした「AudioDE」、Freescaleの「MXC91231」、TIの「C55x+」や「C64+」などは、いずれもプロセッサコアとDSPコアを組み合わせたSoCだ。特定の処理をDSPコアで行なわせることで、いかに高速かつ低消費電力を両立させるかが主なテーマといってよく、Cellの発表もこれに沿ったものとなっている。ゲームコンソールから見たCellはまた別の捉え方があるかもしれないが、組み込みのジャンルから見たCellは、DSPコアを8個持つPowerPC 970の発展版と考えるのが正確であろう。

 IBM自身も(対外的にDSPとは言わないが)、SPEの扱いは限りなくDSPに近いものとなっている。講演の中でCellのプログラミング技法として大きく1つの方法論が示されたが、まずApplication Acceleratorは特定のサービスをSPEに割り当て、OSレベルでこの管理をすることで、(PPE上で動く)アプリケーションはSPEのことを意識せずに使えるというもの。

4つのプログラミングモデルとは、Application Acceleration Model / Function Offload Model / Computation Acceleration / Heterogeneous Multi-Threading Modelである この例の場合、TCP Offload/Data Encryption/Data Decryption/Realtime MPEG Encoding/Compression&
DecompressionといったサービスがSPEで提供され、PPEで動作するアプリケーションがOSなどのAPI経由でこれらのサービスを使おうとするとSPEが動作するという仕組み

 Function Offloadとは、特定のアプリケーションの処理をSPE側で実装してしまい、アプリケーションからこれを直接呼び出すというモデル。Computation Accelerationとは、SPEをRPC(Remote Procedure Call)などを経由してアプリケーションから直接呼び出すという方式で、機能的にはFunction Offloadに近いが、SPEの管理はOS側で行なわれるという点ではApplication Acceleratorに近い。

この例ではOSは介在しないため、基本的にはアプリケーションがSPEのコントロールを行なうことになる。ただ、スライド「Programming Models」の1番下にもある通り、SPEのAllocation/DeallocationやAssign/Freeの作業はOS側で実装するのが現実的であろう Application AcceleratorとFunction Offloadの折衷案。Function指定とパラメータはMailbox経由で、それより大きなデータはSystem Memoryとあるが、これはSPEのLSを直接メモリ空間にマップさせてアクセスする形になるだろう。本当はLSとSystem Memoryを重ねてマップし、coherencyを確保するハードウェアが両者の一貫性を取れればI/O速度は1番速いのだが、実装はかなり面倒になるので、まずありえないだろう

Cell対応OSの中では、SPEのVirtualizationなども実施するとしており、そう簡単に作れるものではないだろう

 最後がいわゆるヘテロジニアスマルチプロセッサシステムであるが、PPE用のタスクとSPE用のタスクを分けるという時点で、そのSPE用Taskをどう作り、どう管理するかが問題になってくる。今のところ、複数種類のCPUコンテキストをまとめて扱えるOSもなければ、複数種類のCPUリソースの割り当てというタスクスイッチの実装例もほとんど聞いたことが無い。これに関しては「今後こういうOSを作ればこんなことができる」的なイメージとして捉えるのが1番現状に近いのだろう。


●製品ラインナップとしてのCell

 率直に言うと、実は筆者はCellはあまり真面目に追いかけていなかった。ゲームコンソールはカバー範囲外としている事や、組み込みプロセッサとしてはあまりに政治色が強い(まだBlueGene/Lの方が、政治的な色合いはすっきりしている)事、後藤氏などのレポートが充実していて今更書くこともないだろうと思っていたあたりが主な理由だが、改めて講演を聞いてみると、立派に組み込みプロセッサであった。

 現状、ゲームコンソール以外への展開と言う点では、

 ・価格が高くなる
 ・性能が(無駄に)高すぎる

というあたりがネックになりそうだ。まず価格はXDR DRAMを使っているのが最大のネックである。猛烈な量の契約を行なっているSCEIは当然それなりの価格で入手できるだろうが、それ以外のベンダーが同じ価格で入手するのは到底不可能であって、入手性と価格の両面でXDR DRAMは敷居が高い。

 性能もまた論外に高い。本来コントローラでしかないはずのPPEですらPowerPC 970相当で、しかも3GHzオーバーというのは、MIPS64ベースのハイエンドコアの2倍以上の性能に相当する。更にSPEをフルに使いきった場合、大抵の組み込みプロセッサが想定している性能より1桁大きいことが予想される。

 ここまで性能ギャップがあると、「では動作クロックを落として性能を下げましょう」とは言いにくい。そんなことをしたら、「なぜXDR DRAMを使う必要があるのか?」という議論になる。DDR/DDR2を利用でき、コアの周波数が1GHz未満、SPEも2~4個程度という「低価格向けCell」でもあれば話は別かもしれないが、今のところそういう予定もないようだ。

 もっとも、これをIBMの製品ラインナップという面で見れば、ローエンドはPowerPC 60xシリーズやこれをベースにしたSoC、ミドルレンジがPowePC 4xxシリーズやこれをベースにしたSoC、ハイエンドがCellというラインナップが完成する。下はARM11/ARM12から上はMIPS64までに対抗できる布陣が揃ったとも言える。加えて、CellによってSPEというDSPコアを手にしたことで、例えばPowerPC 440+SPE×1~2といったSoCも今後は可能になるかもしれない。組み込み向けマーケットをPowerPCアーキテクチャで席巻しようと意気込むIBMにとって、Cellはやはり重要な第1歩といえるのだろう。

□SPF2005のホームページ(英文)
http://www.instat.com/spf/05/
□関連記事
【5月18日】Spring Processor Forum 2005前日レポート
http://pc.watch.impress.co.jp/docs/2005/0518/spf01.htm
【2月18日】【海外】CPUの新しいトレンド「ヘテロジニアスマルチコア」
http://pc.watch.impress.co.jp/docs/2005/0218/kaigai158.htm
【2月12日】【海外】Cellのパワーの源「SPE」の正体
http://pc.watch.impress.co.jp/docs/2005/0212/kaigai156.htm

(2005年5月23日)

[Reported by 大原雄介]

【PC Watchホームページ】


PC Watch編集部 pc-watch-info@impress.co.jp
お問い合わせに対して、個別にご回答はいたしません。

Copyright (c) 2005 Impress Corporation, an Impress Group company.All rights reserved.