計算能力重視のプロセッサCELLとDSPを比較する ―― アーキテクチャ，開発環境，活躍場所など

2．プログラミング環境

　既に触れましたが，PPUのプログラミング環境にはGCCが用いられています．IBM社はGCCによるクロス開発環境だけではなく，LinuxカーネルもCBEのPPUに移植しています．これを利用してPlayStation 3上でLinuxを動作させることもできます．これらのリソースはSDKとしてまとめられており，IBM社のCELL Broardband Engine Resouce Center^（5）からダウンロードできます．しかし，なかなか一筋縄ではいかないこともあるようです．その場合は，フィックスターズのPS3 Linux Information Site^（6）を参考にすることをお勧めします．

　PlayStation 3上で走るLinuxのプログラムを開発する場合，SPUのプログラムもGCCを使って開発します．しかし，コンパイルされたSPUのプログラムは，PPUのプログラムとはリンクされません．SPUのプログラムは独立して完結したプログラムとしてリンクされ，実行時にSPEにダウンロードされます^注1（図2）．



図2 SPUプログラムのダウンロード
SPUのプログラムはPPUプログラムとは独立している．メモリからSPEにロードされる．

注1;プログラ開発はSPU単位だが，ダウンロードはSPEに行うことに注意．後で説明するローカル・メモリをSPE内部のSPUが共有しているため．

　このようにPPUは自らがSPEにダウンロードしたプログラムと同期を取り，データのやり取りを行うことで，負荷の大きな計算をSPEに任せることができます．従って，一度SPEにプログラムをダウンロードすると，PPUからはSPEは強力な演算ペリフェラルに見えます．言葉を変えるとSPUプログラミングは，ペリフェラルのマイクロコード開発に相当します．

　DSPの開発経験のある方ならば，GCCが吐き出すコードが十分に最適化されていないであろうことも想像がつくかと思います．本来GCCは汎用プロセッサ向けに開発されています．SIMD（Single Instruction Stream-Multiple Data Stream）や深いパイプラインといった癖の強いアーキテクチャ向けではありません．米国Texas Instruments社や米国Analog Devices社といったDSPメーカは，GCCではなく専用のコンパイラを社内の専門家に開発させることで自社のプロセッサの性能を最大限に引き出しています．

　GCCのこの欠点は責められる性質のものではありませんが，対策は必要です．CELLのSDKはこの問題の一つの解としてプログラマが直接SPUの命令を書けるよう組み込み関数（Intrincics）を用意しています．演算用の組み込み関数が現れると，コンパイラはそれに1対1で対応する演算命令と置き換えます．これによってSIMD命令のような最適化の難しい命令をプログラマが積極的に活用できるようになっています．

3．SPEの使いこなしが性能を決める

　CBEAでは，PPUプロセッサをPowerPCそのものであるとしています．従ってPPEを使う限り，CBEは汎用プロセッサ程度の演算能力しか示しません．CBEからCRAY-1の1000倍の性能を引き出せるかどうかは，ひとえにSPEの使いこなしにかかっています．

　一方でSPUのアーキテクチャは到底，汎用OSを満足に動作させられるものではなく，リアルタイムOSですらきちんと動作するか心もとないと思わせます．従って生産性を求められる雑務やタスクのスケジューリングはPPEで行い，SPEは計算に専念するのが得策です．この場合，PPEはSPEのI/Oプロセッサとして働くともいえますし，SPEがPPEの演算アクセラレータとして働くともいえます．

　PPEとSPEの間の通信や同期のデザイン・パターンについては，文献^（3）のChapter4に解説がありますので，そちらを参考にしてください．本記事ではSPE/SPUのアーキテクチャに的を絞って話を進めます．