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

中村 健真

tag: 組み込み 半導体

技術解説 2009年5月14日

6.CELLを考える,CELLから考える

 CBEAは,本来あらゆる民生アプリケーションへの浸透を狙って開発されたものでした.そのもくろみの当たり外れは別として,開発チームがどのような視点で「あらゆる民生機器で使われる演算プロセッサ」を開発したのかを考えるのは興味深いことです.

● 汎用プロセッサの方法論で開発されたDSP

 SPUのアーキテクチャを見渡してみると,基本理念,実装のいずれもが汎用プロセッサの方法論で開発されていることが見て取れます.それらは組み込み用のDSPとは幾分方向性を異にしています.既存の汎用DSPの中で幾分でも近い方向のものがあるならば,それはTexas Instruments社のTMS32C6000シリーズでしょう.
 

集積度の向上を活用する
 SPUのアーキテクチャを見ると,ハードウェアを簡単にしてコンパクトな設計にしようとしているように思えます.小さなプロセッサは,集積度が向上したときにいち早くマルチプロセッサ化が容易になります.CBEは8基のSPUを持っていますが,集積度の向上によってさらに多くのSPUを実装できるように初めから配慮されたアーキテクチャになっています注4

注4;ただし,これまでSCEは2度のプロセス微細化でSPUの数は増やしていない.


速度の向上を図る

 SPUのパイプラインは,DSPがよく使う早期ロード命令実行などは行わず,シンプルな構成になっています.また,命令デコードに関してもx86のような凝ったデコーダではなくシンプルです.そして,遠慮なく深いパイプラインを実装しています.

こういった方向性のおかげで実行速度は3GHzを超えています.CBEAが策定されたのはx86でIntel社とAMD社が激烈な周波数競争を繰り広げていたころです.CBEの開発にあたっては当時のこの風潮が大きく影響したと考えられます.

 ただしx86,特にPentium 4は周波数が上がった割には実行効率が低く,発熱ばかりが大きいという結果になりました.Intel社はこの反省を受けて大きくかじを切り,低い周波数でも実行効率の高いCoreアーキテクチャを開発しました.CBEAは,パイプラインが長い場合でもループ・アンロールとインターリービングを使ってストールが少なく実行効率の高いプログラムを開発できるよう工夫されています.

 デュアル・ロード命令がない点も,複雑化を避けて速度の向上を選んだ結果ではないかと思われます.



コンパイラ技術を利用する
 SPUは非対称のパイプライン,分岐ヒントなどアセンブリ言語で書くには幾分扱いの難しい部分があります.これらは初めからコンパイラ技術がカバーしてくれることをもくろんでいると思われます.

 より並列度の高いSIMDを使えば,ピーク性能は向上したと思われますが,あえてそれを避けてx86やPowerPCで見慣れた4並列単精度浮動小数点演算中心にまとめたあたり,コンパイラを頼る方向性がうかがえます.



重要なのは生産性と平均性能である

 DSPの設計では積和演算の実行効率向上が大命題になります.これを実現するためにデュアル・ロード,演算とロードの同時実行,短いパイプライン,特殊なアドレッシング・モードなどが正当化されていました.

 一方,SPUはDSPというよりも,x86やPowerPCのSIMDユニットを中心にアーキテクチャの簡素化を図っていったような構成になっています.この構成には辛うじてパイプラインのインターロックが残っていますが,強力な命令デコーダ,リッチなビット・フィールド演算,仮想記憶機能などが取り払われ,かつ,DSP式のアーキテクチャもほとんど用いられていません.ハードウェアの簡素化は周波数向上に振り向けられています.その代わりにレジスタ数が極端に増やされています.

 DSPではなく汎用マイクロプロセッサを出発点にすることでCコンパイラを開発しやすくし,アーキテクチャ上の弱点を周波数で補っているのがSPUの方針のようです.

 DSPの分野でも開発はC言語に移ったのでSPUの選択は歴史的には間違っていません.ただし,コンパイラがSPUの掲げた理想に追いついたかどうかは疑問です.SIMD化はDSPの最適化技術でも最も難しいものです.さらさらと書き下したソースがアーキテクチャに対して最適にコンパイルされることはまれです.一般には,そのアーキテクチャ向けにアルゴリズムやデータ構造を書き直す必要があります.

 SPUの性能を搾り出したければ,枠組みをCで書いて一番内側のループをアセンブリ言語で書くアプローチが有効だと思われます.

● CELLが活躍する分野

 本来CELLは計算能力重視のプロセッサとして,家電そのほかで広く使われることを目的として開発されました.家電ではPlayStation 3で使われているだけですが,東芝やIBM社はまだ産業機器分野への売り込みを続けています.そこでCELLがどういった方面に使えるのか考えてみましょう.



演算集積型のアプリケーションは意外に多い

 今世紀に入って画像をディジタル処理する技術が一気に普及しました.ディジタル・カメラが主導する形で始まったこの動きは,ディジタル・ビデオ,地上デジタル放送で完全に一般化しています.

 民生用の機器の場合,信号処理部はほぼ確実にSOC化されるため,CELLのような汎用チップによる信号処理が入るすき間はほとんどありません.ところが,市場がこれだけ大きくなると,派生市場がたくさん生まれてきます.例えば放送機器がその代表です.放送機器はテレビのように何千万台も売れるわけではありませんから,開発費が億単位になるようなSOCを使うわけにはいきません.こういう分野では強力な演算機能を持ったプロセッサが望まれます.

 医療用機器も演算能力を常に渇望しています.CTスキャナや超音波スキャナといった可視化装置では,常にもっとよく見えるように,もっと細かく見えるように,もっと早く見えるようにと要求が積み重なっていきます.その上,末端まで検診が行き届くように制度が進んでいるため,常にポータブルな機械が要求されます.この分野でも圧倒的に高い演算能力が求められていますが,SOCを売り込むには市場が小さいという問題があります.

 演算能力を求める機器のためのアプローチはだいたい三つあります.一つはDSPで,Texas Instruments社やAnalog Devices社のプロセッサを使うことになります.これらは,いずれも浮動小数点演算に関する限り周波数は数百MHzどまりです.ただし熱効率は非常に高く,開発に関しても次第に敷居が低くなっています.

 二つ目のアプローチはx86を使うことです.小型のきょう体に入ったパソコンを使えば,Intel社のCoreやAMD社のAthlonのような強力なプロセッサを使えます.この方式はソフトウェア開発環境が充実しており,開発者も多いのが特徴ですが,x86系のプロセッサの特徴で,ピーク演算能力を維持し続けるというわけにはいきません.また,システム全体からみた熱効率は,改善されたとはいえ,かなり悪くなります.

 三つ目のアプローチはFPGAです.FPGAは必要な信号処理パイプラインをそのまま実装できる強みがあります.熱効率も高いのですが,回路そのものの設計になること,演算周波数がそれほど高くないことが欠点です.

 CELLプロセッサは4番目の選択肢になり得るでしょうか.筆者はなり得ると思っています.前例を重んじる傾向にある大手家電メーカでは採用されにくいと思われますが,実質,日本の産業を支えている中小を含めた産業機器メーカにとっては,選択肢足り得るでしょう.SPUの開発は確かに敷居が高いですが,ほとんどの部分はC言語によるプログラムです.また,PPE部にLinuxが提供されているため,通信やストレージ管理はLinuxプログラミングそのものであるという強みもあります.



研究と製造の境界

 中期的に見たとき,CBEが一番強みを発するのは製造との境界にあるようなアプリケーションでしょう.CBEはCRAY-1の1000倍にも達する演算速度を持ちながら,街では4万円そこそこで売られています.実行環境はLinuxであるため学生でもプログラミングを始めやすく,チューニングによってどんどん速度をあげることができます.しかも,ネットワーク接続可能であるため,比較的容易にクラスタリングを行うことができます.実際に,PlayStation 3を使った分散コンピューティング計画が存在します.

 パソコンよりも計算速度が速く,しかも同じコストをつぎ込めばクラスタリングが可能なPlayStationは,研究結果のシミュレーションに利用可能でしょう.研究室でスーパーコンピュータをがんがん使えるのであれば,それに越したことはありませんが,PlayStation 3には購入してしまえば使用料金を取られる心配がないという利点があります.

 1年間に実行できるシミュレーションの数が多ければ多いほど研究で優位に立てます.しかもPlayStation 3はハードウェアが完成しているため,FPGAと違ってハードウェア開発コストとそのリスクがありません.



CELLが強い分野は日本が弱い分野なのか

 数年前からMooreの法則は減速傾向にあります.微細化は進んでいますが,発熱の壁がだんだん高くなってきました.また,民生用のパソコンが機能的にも速度的にも十分な状態に達してしまったため,Intel社やAMD社はプロセッサの高速化から方向を転じつつあります.

 この結果,CBEの機能向上が図られなくても,しばらくはCBEの性能的優位が保てそうです.現在はコンパイラを使ってもパソコンより十分早い演算能力を持っていると考えられますが,手作業でボトルネックを最適化してやれば,圧倒的な優位が続くでしょう.

 Mooreの法則が健在だったころは,少し待てばすぐにパソコンのハードウェアの性能が上がりました.ですから,高速のハードウェアを見繕って苦労して実装することに幾分のむなしさが付きまといました.しかし,こういう状況になってくると,腰をすえてとんがったハードウェアに付加価値の高いテクノロジを実装するビジネスも十分生きてきます.

 問題は,そういったビジネスに前向きな研究者の数です.もともと日本では大手企業の資材部がベンチャ企業を嫌い続けたため,研究者がベンチャ・ビジネスに乗り出すという意識が希薄です.結果,多くの研究者が「ビジネスは自分の仕事ではない」として実装に無関心な態度を取っています.

 しかし,中国をはじめとする諸国がエレクトロニクス市場に続々と押し寄せてくるようになった今,誰でも作れる製品を作っていては生きていけません.企業はより先端で高付加価値の製品を出さなければなりませんし,そのためには実装まで視野に含めた研究が必要になっています.

 筆者はOPアンプ回路の置き換えに「倍精度浮動小数点演算が必須」と主張して譲らない研究者と話したことがあります.よくよく聞いてみると彼の作ったシミュレーションが倍精度で動いているから,製品も倍精度が必要とのことでした.コスト意識に首をかしげたものです.「xxじゃないとできない」と言い切る研究者はよく見かけますが,大抵市場は簡略化された実装で動いています.早い者勝ちなのです.

 確かにCBEのピーク演算能力は単精度浮動小数点演算でしか生きません.しかも,その演算精度はIEEE 754の仕様より幾分劣るものです.そうした特性を忌避するか,あるいは克服するかで,目の前の低価格ハードウェアを使って研究を進めることができるか否かが変わります.せっかく強力なプラットホームがあるのですから,活用してみてはいかがでしょうか.

参考・引用*文献
(1 )CELL Broadband Engineアーキテクチャ Version 1.01,ソニー・コンピュータエンタテイメント.
(2 )Synergistic Processor Unit命令セット・アーキテクチャ Version 1.2,ソニー・コンピュータエンタテイメント.
(3 )Software Development Kit for Multicore Acceleration Version 3.0,IBM.
(4 )Cell Broadband Engine Programming Handbook Version 1.1,IBM.
(5 )developperWorks : CELL Broadband Engine Resouce Center,IBM.
http://www.ibm.com/developerworks/power/cell/index.html
(6 )PS3 Linux Information Site,フィックスターズ.
http://cell.fixstars.com/ps3linux/index.php
(7 )下馬場朋禄,伊藤智義;CUDA技術を利用したGPUプログラミングの実際,Interface,2008年6月号.
(8 )Denormal numbers in floating point signal processing applications,Laurent de Soras,2005.
(9 )Intel 64 and IA-32 Architectures Optimization Reference Manual,2007,Intel.
http://www.intel.com/products/processor/manuals/
(10)堀江誠一;Blackfin活用ハンドブック,CQ出版社,2005年.

 

なかむら・たけまさ
 

組み込みキャッチアップ

お知らせ 一覧を見る

電子書籍の最新刊! FPGAマガジン No.12『ARMコアFPGA×Linux初体験』好評発売中

FPGAマガジン No.11『性能UP! アルゴリズム×手仕上げHDL』好評発売中! PDF版もあります

PICK UP用語

EV(電気自動車)

関連記事

EnOcean

関連記事

Android

関連記事

ニュース 一覧を見る
Tech Villageブログ

渡辺のぼるのロボコン・プロモータ日記

2年ぶりのブログ更新w

2016年10月 9日

Hamana Project

Hamana-8最終打ち上げ報告(その2)

2012年6月26日