ノート:Cell Broadband Engine

第一義は細胞のことなので、曖昧化するのがいいかもしれない。--mochi 2005年2月8日 (火) 13:59 (UTC)[返信]

搭載製品の一般発売がまだの製品なのですが、記述があたかも一般的に認められているような表現が多く、ちょっと気になりますね。新製品タグ貼っておきますが、問題がありそうでしたら剥がしてください。yfuruhata 2005年12月27日 (火) 10:39 (UTC)[返信]

低性能[編集]

「逆に個々の性能では、現行のCPUに比べはるかに劣るため、いかに複数のコアを使うかがCellの性能を左右する。」の文ですが、これはGAME Watchにあるように、PPEはそのようですが、SPE１個に関してはPentium4(@3.2GHz)の１倍から１．５倍と書かれています。もちろんアプリケーションの内容や最適化しだいで大幅に変動するはずですが、上述の「はるかに劣る」はありえなさそうです。PPEに関しては情報サイトにも数多く書かれているようにSPEのマネージメントCPUであって処理の中心となるべき場所ではないため、比較対象外でしょう。従って今回はまずコメントアウトさせてもらいます。議論はこのノートの続きでお願いします。--ちぇす 2006年5月30日 (火) 14:53 (UTC)[返信]

新製品タグ[編集]

新製品タグが貼られていますが、Cell自体はマーキュリーコンピュータのシステムに搭載されて数カ月経つため、このタグを外そうと思いますが、いかがでしょうか。--ちぇす 2006年9月1日 (金) 01:55 (UTC)[返信]

SPUの性能[編集]

「対象アプリケーションやルーチンがSIMD命令を頻繁に実行し、かつLSとXDR DRAM間のメモリ転送の頻度が少ないものであれば、SPE1個で3.2GHz Pentium4の1～1.5倍程度の性能を見込むことができる。」という文で、「かつLSとXDR DRAM間のメモリ転送の頻度が少ないものであれば」の部分が追加されましたが、参考資料1にある「Pentium4の1～1.5倍」の件にはそのような条件は書かれていません。この追加文の継続掲載には相応の資料が必要でしょう。--ちぇす 2006年10月6日 (金) 17:42 (UTC)[返信]

資料がなくても分かることです。(1)DMA転送が終わるまでSPEの行動が制限される。ダブルバッファを使っても限界がある。LSが少ないのでダブルバッファの実装も困難。(2)コード領域とデータ領域が共用で256KBしかないので大きなデータを扱うにはDMA転送が必須になるが、性能低下は免れない。(3)XDR-DRAMの帯域はPPE+SPE×7が頻繁にアクセスするには帯域が不足なので、SPEはできるだけXDR-DRAMに対してDMA転送しないようにする必要がある。--Monadaisuki 2006年10月6日 (金) 18:15 (UTC)[返信]

実測値から出した定量的データ(1～1.5倍)に対し、そのアルゴリズムがどの程度のメモリ転送頻度を持っているのかや、Pentium4のボトルネックとの対比などがわからなければ、この文脈でその条件を出すことはできません。「メモリ転送の頻度が少ない」って定量的にどれくらいでしょうか。気を付けなければすぐにその条件に当たるのか、よっぽどデータ移動過多でなければその条件に当たらないのか、判明しているのでしょうか？

(1)(2)で「ダブルバッファの実装も困難」「性能低下も免れない」となっていますが、後藤弘茂のWeekly海外ニュースでは「SPE内部でダブルバッファリングにより処理を途切れさせないことが可能」となっています。--ちぇす 2006年10月7日 (土) 02:16 (UTC)[返信]

後藤弘茂氏のような提灯記事ばかり書く人の記事を引用されても説得力はありません。というかご自身で考察されては如何ですか?

(1)(2)については、LSが256KBしかないのがその根拠です。音声のデコーダーのように扱う単位が少ない場合はダブルバッファも可能でしょう。例えばMP3デコーダーを想定しますと、出力は1フレーム1152サンプルなのでステレオ16bitで5KB以下です。1入力フレームを320kbpsと仮定しても1KB程度です。この場合ですと、入出力をダブルバッファにしても必要なメモリは(5+1)*2で12KB程度ですから何とかなると思います。ただし、IMDCT、バタフライ演算、逆量子化、ハフマン符号を解くバッファ、そして、コード部分の容量を考慮するとあまり余裕はありません。参考ですが、私の手元にMP3のソースコードdist10[1]がありますので、手元のMacOSX(PowerPC7400)上でコンパイルしてみました。デコーダーのバイナリサイズはストリップして約60KBです。命令長の長いSPEだとこれよりも遥かにサイズが大きくなると思われます。SIMD命令を使うとさらに肥大化します。そうなると音声デコーダーでもLSの容量はあまり余裕がないと思われます。これがAC3のようなマルチチャンネルデコーダーになりますと6chのデコードが必要ですのでさらにメモリの余裕はなくなります。

これが動画デコーダーになると、256KBでダブルバッファなんて最初から考えるべきではないのです。例えば、480Pの出力でも640*480*3=921600byte=900KBもバッファが必要なのですから。この場合は、LSをシングルバッファにして、一枚丸ごとデコードするのは無理としてもできるだけブロックをまとめてデコードすることを考えた方が良いと思われます。その代わり、SPEを複数使ってパイプラインを組めば、シングルバッファでもスループットは向上できます。その代わり、SPEを大量に使う必要があります。

(3)については、SPE一個当たりのDMA最大転送速度が3.2GHz×128bitですので47.7GB/secとなります。一方、XDR-RAMの帯域は25.6GB/s。SPEが7機とPPEでこの帯域を使いますので、メモリ帯域はちっとも足りません。SPEができるだけ作業をLS上で行い、メインメモリのアクセスを最小限にすることが前提なのは少し考えるだけで明白です。

--Monadaisuki 2006年10月7日 (土) 09:15 (UTC)[返信]

個別の疑問点から

> デコーダーのバイナリサイズはストリップして約60KBです。命令長の長いSPEだとこれよりも遥かにサイズが大きくなると思われます。SIMD命令を使うとさらに肥大化します。

SPEの命令長は固定32bit[2]ですが、長い、遥かにサイズが大きくなるとはどこら辺を指しますか？またSIMD命令を使うとさらに肥大化とありますが、SPEはデフォルトが既にSIMD命令のようですが（もちろん32bit）、どこら辺が肥大化の要因でしょうか。

SIMD命令を使うというよりSIMDの4スロットのマネジメントに命令が使われるという事はありましょうが、専用命令により小命令数でできそうな感じです。

次に動画デコーダですが、

> LSをシングルバッファにして、一枚丸ごとデコードするのは無理としてもできるだけブロックをまとめてデコードすることを考えた方が良いと思われます。

とありますが、なぜできるだけブロックをまとめた方が良いのでしょうか。MPEG2デコードなどは16x16のブロックサイズで独立しているのだから、SPEの処理効率の良いブロック数（もちろんマルチバッファリングできる粒度）を1単位としてストリーミング処理すればよいのでは。シングルバッファとしてまでもまとめる理由がよくわかりませんでした。

> SPE一個当たりのDMA最大転送速度が3.2GHz×128bitですので47.7GB/secとなります。一方、XDR-RAMの帯域は25.6GB/s。SPEが7機とPPEでこの帯域を使いますので、メモリ帯域はちっとも足りません。

確かにSPEを単なるDMA代わりに使うのならそうなるでしょう(51.2GB/sではなくて47.7GB/secですか？)。SPE7個だと358.4GB/s。つまり理論的カタログスペック的には14op/dataでバランスする（当然この数字はバスのコンフリクト、バーストアクセスによる冗長性、その他の要因により悪化するでしょうし、逆に演算側がストールすることも考慮する必要がある）。これが演算比重が高い処理が得意と言われる要因とは思いますが、「メインメモリのアクセスを最小限にすることが前提」とまで言い切るには諸々のアルゴリズム、ルーチンがどれくらいのop/dataを持つのかを知っているなど、アクセスを最小限にする努力をどれ位する必要があるのかを知っている必要があります。定性的に適当に最小限にしなければならないわけはなく、どのような機構にもバランスがある。そのバランスを知っているのですか？ということです。

また前述の音声ストリーミング処理などではデータよりも命令格納領域の問題を指摘されていましたが、そのようなつまり演算過多な処理の場合は逆に処理パイプラインをカスケードに分断し、テンポラリバッファをメインメモリに持つことも考えられる。要はデータと演算のバランスにより処理をどうブロック化、階層化するかでしょう。

私はだからといって、このような事をCELLの記事に出来るとは思いません。結局のところこれらは推測の域を脱しておらず、Wikipedia:検証可能性を満たせません。そんなの資料がなくても計算すればわかるだろ、では掲載できません。--ちぇす 2006年10月7日 (土) 12:34 (UTC)[返信]

時間がないので完結にお答えします。

＞SPEの命令長は固定32bit[2]ですが、長い、遥かにサイズが大きくなるとはどこら辺を指しますか？

これは私の書き方が悪かったですね。C言語で書かれたソースコードを変換したとき、置き換えられた機械語のコードが冗長になるということです。個々の命令はおっしゃるように32bitです。

＞SIMD命令を使うというよりSIMDの4スロットのマネジメントに命令が使われるという事はありましょうが、専用命令により小命令数でできそうな感じです。

C言語で記述したコードをSCEの提供するgccコンパイラが最適にコンパイルできるとは思えません。実際にはCソースコードの中にアセンブラ記述命令のようなものを駆使してプログラミングできると思われます。SIMDによる高速化を有効に活用するにはループアンロール化や分岐ヒントの埋め込みが必要です。LS上のメモリをバイト操作するには、128bit単位でレジスタに読み込んで、1バイトだけ操作して書き戻す必要があります(レジスタ上ではShuffle Bytes が使えますが)

＞とありますが、なぜできるだけブロックをまとめた方が良いのでしょうか。＞シングルバッファとしてまでもまとめる理由がよくわかりませんでした。

DMAにはレイテンシがあるからです。小単位の転送を繰り返すとレイテンシによって損失が生じます。

＞(51.2GB/sではなくて47.7GB/secですか？)

おっしゃる通りです。当方の計算ミスです。（何故間違えたのだろう？）

＞SPE7個だと358.4GB/s。つまり理論的カタログスペック的には14op/dataでバランスする

いえ、PPEの分も考えて下さい。Cellの理論上の最大は51.2GB×8=409.6GB/sになると思います。PS3の場合ですと、RSX(20GB/s)やSouthBridge(2.5GB)の分も考慮する必要があります。全体で432.1GB/sです。17op/dataでバランスすると言いたいところですが、リングバスによるレイテンシも考慮するとさらに多めに考える必要があるでしょう。かなりバランスが悪いアーキテクチャだと思いませんか?

＞定性的に適当に最小限にしなければならないわけはなく、どのような機構にもバランスがある。そのバランスを知っているのですか？ということです。

実機のバランスを知らなかったら、バランスの悪いハードを作ってもいいという考え方は日本のハード技術者に多い悪しき考えですね。考察時点でバランスが悪いものは作るべきではないでしょう。

＞結局のところこれらは推測の域を脱しておらず、Wikipedia:検証可能性を満たせません。

それを言ったら、SCEが発表する「検証可能性がありそうなだけ」の発表やインプレスの提灯記事を鵜呑みにするのもWikipedia:検証可能性を満たしていないと言えませんか？少なくとも我々は計算で検証しているではありませんか。

8日は都合で返信できませんのでご注意ください。--Monadaisuki 2006年10月7日 (土) 14:03 (UTC)[返信]

> C言語で記述したコードをSCEの提供するgccコンパイラが最適にコンパイルできるとは思えません。・・・（中略）・・・、1バイトだけ操作して書き戻す必要があります(レジスタ上ではShuffle Bytes が使えますが)

最適化の話だったのですね。AltiVecだけを抽出したようなSPEでgccは多少無理があるのかと。基本的にintrinsicかと思っていましたが。しかしアンロールなどコードの肥大化はop/dataが改善する方向（気を付けなくてもメモリ転送頻度が減る方向）だから議論の本質ではなくなっていますかね。

本質でないついでに、「SIMDによる高速化を有効に活用するにはループアンロール化や分岐ヒント」はSIMDに限らず単純なRISCチップに対するアセンブラでの高速化の基本テクかと。OoOではない、分岐予測がないというのが要因ですね。

> DMAにはレイテンシがあるからです。小単位の転送を繰り返すとレイテンシによって損失が生じます。

> リングバスによるレイテンシも考慮するとさらに多めに考える必要があるでしょう。

これらレイテンシに関する記述もよくわかりません。転送系のレイテンシを隠蔽化するのがマルチバッファではないのですか。ダブルがだめならトリプルで可能かと。通常レイテンシの深さに合わせてFIFO段数などを決めますよね、それと同じかと。また小単位ではなく適切な単位で行うのでは。例えば16kBだったら最小で2048cycは稼げるわけで。従ってop/dataの議論とは無関係かと。

> いえ、PPEの分も考えて下さい。Cellの理論上の最大は51.2GB×8=409.6GB/sになると思います。PS3の場合ですと、RSX(20GB/s)やSouthBridge(2.5GB)の分も考慮する必要があります。全体で432.1GB/sです。

まぁここはPS3ではなくCell単体の議論なんで。とは言っても無意味な数値ではしょうがないので、前提によっては必要ですかね。またPPEを演算能力に加算せずマネージャに徹する前提であれば、XDRとのアクセスが頻発するという仮定は成り立たないのでは(512kBのキャッシュにヒットする前提)。

> 実機のバランスを知らなかったら、バランスの悪いハードを作ってもいいという考え方は日本のハード技術者に多い悪しき考えですね。考察時点でバランスが悪いものは作るべきではないでしょう。

Cellがバランスが悪いかどうかは私にはわかりません。というか各アプリケーションが全て同じバランスであるなどということがない、という意味では全てのアプリケーションにマッチしている機構などというものは存在しない。Cellが演算側にバランスが振られているのであれば、圧縮展開やデータ生成、CGなどのようにデータをこねくり回す物には都合がいいのでは（というかそれが想定アプリなのでは）と思うのですが、いかがでしょうか。逆に単純で多量な演算やランダムアクセスの多いものなどには都合が悪い（というか想定アプリではない）のかなと。というか実際問題そんなにバランスが悪いんですかね。

> それを言ったら、SCEが発表する「検証可能性がありそうなだけ」の発表やインプレスの提灯記事を鵜呑みにするのもWikipedia:検証可能性を満たしていないと言えませんか？少なくとも我々は計算で検証しているではありませんか。

少なくとも私はここで検証している傾向や数値に責任を持てません。ターゲットを触ったわけではなく仕様も公開されているものしか見れず、その殆どは推測でしかないからです（しかしスペックはかなり公開されている方なので想像して遊べますがね）。もちろんMonadaisukiさんにはMonadaisukiさんの前提があるとは思いますが。

私も長々と言っておりますが、元々の議論はPentium4の1～1.5倍という数値の前提に対す議論なわけで、そもそもそれが判明していないのに1～1.5倍を（条件が付いているとは言え）汎用的に用いている現在の記述の問題があったわけですね。1～1.5倍の事例もあるといった程度かなと。

> 8日は都合で返信できませんのでご注意ください。

ごゆっくりどうぞ。--ちぇす 2006年10月8日 (日) 03:16 (UTC)[返信]

不毛な議論になりつつあるので話を戻します。私は元の文章の「対象アプリケーションやルーチンにもよるが、SPE1個で3.2GHz Pentium4の1～1.5倍程度の性能を見込むことができる。」という記述が、分かりにくいと思った訳です。特に「対象アプリケーションやルーチンにもよるが、」という部分です。このような書き方ではアプリケーションやルーチンのどういう部分に依存するのですか？という疑問が生じます。この答えは、LSとXDR DRAM間のメモリ転送の頻度、ベクタ演算(という意味で私はSIMD命令と言っている)の頻度、そして分岐命令の実行頻度によるとしか言いようがないのです。
それと「1～1.5倍程度の性能を見込むことができる」という記述も問題があります。PPEはアウトオブオーダーがないため、同一クロックのPentium4の1/5程度の性能しか出ません。ですので、同様にアウトオブオーダーがないSPEの性能も普通に考えればPPEと大差ないはずです。SPEが高速なのは高速メモリLSによるところと、ベクタ演算に特化した点だと思います。「1～1.5倍程度の性能を見込むことができる」という記述だと、SPEに不向きなアプリでもPentium4の1倍は性能が出るように思われてしまいます。
ここで、提案があります。SPEの問題になっている文章を以下のように書き換えませんか?
- 対象アプリケーションやルーチンの内容（LSとXDR DRAM間のメモリ転送の頻度、ベクタ演算の頻度、分岐命令の実行頻度など）がSPEに向いていれば、SPE1個で3.2GHz Pentium4の1～1.5倍程度の性能を見込むことができる。
「多い少ない」という記述は取り下げますので、これなら問題はないのではないでしょうか?--Monadaisuki 2006年10月9日 (月) 03:57 (UTC)[返信]

私は当初Monadaisukiさんが記述した「LSとXDR DRAM間のメモリ転送の頻度が少ないものであれば」という文言に対し、そのような条件が（参考資料1）には書かれていない、という所から議論を開始したわけですが、議論をしていく過程でそもそも元の文章にあった「対象アプリケーションやルーチンがSIMD命令を頻繁に実行し」も怪しければ「SPE1個で3.2GHz Pentium4の1～1.5倍程度の性能を見込むことができる」も怪しい。この参考資料はIBMが作成したプログラムをベンチマーク代わりに使っているが、IBMがPentium4@3.2GHzをどこまで最適化したのか、SPEプログラムの方はどうなのか、アルゴリズムも双方に得意なものを用いたのかそれとも同一なのかまったく不透明。こんな条件ではとても「1～1.5倍を見込む」と言う事はできないのではと思うようになりました。これは多い方にも少ないほうにも同様であり、内容や最適化方法によっては0.5倍かもしれないし、逆に3倍ぐらいの性能差を持つかもしれない（1.5倍が最大ではないかもしれない）。わからないということです。

つまりこの参考資料から言えるのは、ただ単に

IBMの示した物理挙動シミュレーションとレンダリングの例では、Pentium@3.2GHzとSPE@2.1GHzで1.5倍の性能差を記録したものも提示された

としか言えない、ということです。この資料で1.5倍の性能を見込んではならないし、逆に1.5倍以上は出ないと思うのも違うのではないかと思うようになりました。--ちぇす 2006年10月9日 (月) 06:42 (UTC)[返信]

ちぇす氏のおっしゃる通りかと思われます。「対象アプリケーションやルーチンがSIMD命令を頻繁に実行し、かつLSとXDR DRAM間のメモリ転送の頻度が少ないものであれば、SPE1個で3.2GHz Pentium4の1～1.5倍程度の性能を見込むことができる。」という記述をちぇす氏の文章に置き換えれば良いと思います。--Monadaisuki 2006年10月9日 (月) 08:38 (UTC)[返信]

変更してみました。8基で12倍という部分が元の文章にも参考資料にもあったため追加してみましたが、冗長そうであれば削除もありかと思います。--ちぇす 2006年10月9日 (月) 22:24 (UTC)[返信]

とりあえずこれで良いのではないでしょうか。修正して頂きましてありがとうございました。--Monadaisuki 2006年10月10日 (火) 14:27 (UTC)[返信]

沿革の要出典[編集]

2005年3月31日　Cell に Transmeta社の省電力技術「LongRun2」を組み込んでいくことを発表した http://pc.watch.impress.co.jp/docs/2005/0401/transmeta.htm