【東芝,IBM】Cellプロセッサってどうよ？【ソニー】

いや、コボラーｖｓＭＡＣオタ＋録音（ＣＥＬＬ信者）
ひょっとするとＭＡＣオタ＝録音

まあ、メモリ領域の排他や同期機能が実装されているなら、真っ先に発表されている
それが無いっていう事は実装されていない確率がたかいんだよね

噂の録音って、延々と話題をループさせちゃうんだっけ・・・。

昨日書かれた事に納得出来ないなら、もう何も言う言葉はないかもね。
どんな資料を示そうと納得しないって事なんでしょ。
>>842みたいな事まで書いてしまう位だし。
誰の言葉も届かないのだろうね。

コプロでシングルコアプロセッサだと思いこみたければ思ってれば？
いくらそう主張してもこのスレを読み返した第三者がどう思うかは別だろうけど。

>>904
録音は日本語が通じなくて、突き詰めると自分定義を語りだす池沼だから、この人は別人でしょと、
録音トリップをばらした俺が言ってみる。

>>899
　　-------------------------
　　それはPPEではマルチスレッドが可能だと言いたいのですか？
　　-------------------------
違うす。
BeBox BeOS 603e MESI くらい羅列してもう一回検索し直すことをお勧めするす。

"603e" じゃなくて "603"の方が良さそうすね。

そーそー、録音はＭＡＣオタかそのお仲間の方

>>908
いや、このスレには録音はまだいないと思うよ。

>>906
いや、申し訳ないが漏れがBeの知識を１から付けるのは大変なので…
要点が書いてあるところをリンクなり抽出してもらえると嬉しい。
正直、何を主張されたいのか、さっぱり解らない。

>>895
マルチスレッドのプログラミングの仕方なんてようしらんが、
単純に考えれば、なにもDMAがそんなことやらんでも、
現在の進行状況をPPEが把握していればそれでいいのではないか?

PPEは、SPEに対してJobを振り分けたり、開始を指示したり、SPEから結果を
受け取ったりできるわけだろ(それこそ関数みたいに）

それなら、今その瞬間ではどのような状態か把握し、制御するのは簡単だと思うが…

たとえば、
完成済み　A:20　B:15
作成中 A: 4 B: 3　
残り A:26 B: 32

↑のように常に状況をPPEが把握していればいい。
このテーブルは、SPEに指示をだしたり、SPEから答えが返ってくるたびに更新すれば
それですむ。

ケーキを1個作成終了して、一時手の空いた終了したSPEは見かけ上PPEからの次の指示
があるまで遊んでいることになりそうなものだが、
その間は、そのSPE内でケーキ作りとは別のスレッドを集中して進めれば
いいだけのことじゃないの？

このようにすれば、（ストールが無いとは言わないが）ストールを低減させることは
できるだろ。

この例えの場合のキモはテーブルの管理をPPEがきちんと行えるようにプログラミング
できるかどうかだが、そんなに難しいことか?

>>910
>>898で私が引用したようなモノわ無くても、ご立派なマルチプロセッサOSわ動くという例だと思っておけば
良いす。

ちなみにgoogleで検索して見つかるのわ、たった7件すから全部読んでも罰があたるような話じゃないす。
最初から検索すらしないのわ、単なる釣りでやってるからなんすかね？

>>912
素人煽って嬉しいか？

>>913
>>814あたりを読めば、誰が煽りさんなのかわ明らかかと。。。

>>911
尤もです。まったく正解だと思います。
先ずご理解いただきたいのですが、漏れはSPEの存在自体を否定しているわけでは無いということ。
ただSPEの活用には一定の足枷があり、PPEが主プロセッサ、SPEはPPEのサポートを行う副プロセッサ(=コプロセッサ)
と、言うモデルしか動きようがありませんよ。と。
ご指摘のケースは正にそれです。
根本的なコンセンサスが離れていますので、先ずは少しずつ近づいていきたいのです。

録音は降臨してないのかもしれないが、性質は似ていると思うけどね。
まぁ(2)の人は(1)と違って議論に罵倒を混ぜない分全然マシなんだけど、
言葉の定義がどうも俺定義っぽいあたりがね・・・。

>ただSPEの活用には一定の足枷があり、PPEが主プロセッサ、SPEはPPEのサポートを行う副プロセッサ(=コプロセッサ)
主プロセッサ、コプロセッサの定義は何？
結局貴方の主張は言葉遊びの領域としか解釈できない。

そもそも、何が言いたいの？
仮にコプロセッサだとして、それで何を指摘したいの？

>>912

解りました。読みますので少し時間をくださいね。

>>914
>>814あたりを読めば、誰が煽りさんなのかわ明らかかと。。。

まだ実機も無ければ、断片的な情報しか出ていないわけです。
出ている情報から推論する以外に方法は無いですよね？
既に出ている情報で>>894-896を否定できる物が有るのなら下さい。
無いのならば、貴方も推論でしか有りません。

>>916
言葉遊びには興味が無いと言われるのならばそれまでですが…
結局はPPEが頑張ることになるんだよ！
と、言いたいわけです。
SPEは断片的にしか使えないよ。残念ながら。
と。

なぜ秘書がケーキの具体的な数字を把握する必要があるの？
SPEから「Aケーキいっちょあがり」PPEから「Bケーキひとつ追加」っていう
相互連絡が通じればいいだけだろ
全体の状況を把握するのはPPEの仕事だろうに

>>918
用途によるんじゃね？

>>918
そこがわからん。

>>911に挙げたプログラミングモデルを受け入れた上でなんで、

> 結局はPPEが頑張ることになるんだよ！
> SPEは断片的にしか使えないよ。

という結論になるの?

論理展開が飛びすぎていると思うが…
（少なくとも、911から915に至るまでの説明が必要でしょ）

PPEもSPEも頑張るって結論にはならないの?

というか、おそらくCell自体は、大量の座標計算や物理計算を
高速に行えることをターゲットとして設計されているわけで、
その使用目的に従った用途(ゲーム）では
それこそSPEが主に活躍するわけで、

OSやSPEの動作状況の管理に主に行う事になる
PPE の負荷はそれほど高くないと思うんだが…

>>919
>なぜ秘書がケーキの具体的な数字を把握する必要があるの？

しらんがな(´･ω･｀)
SONY様がメモリアクセスはDMA(秘書)を通せとおっしゃるからです。
漏れに言われても困ります。

ソースが必要ですか？
ttp://www.watch.impress.co.jp/game/docs/20050316/ps3.htm
>また、SPEはCELLに接続されたメインメモリへDMAを介してアクセス能力を持つものの、
>SPE自身はメインメモリにあるソフトウェアを直接実行することはできない。
>SPE各自がもっている256KBのローカルストア(LS:Local Store)と呼ばれる自己メモリ空間に
>ソフトウェアやデータを持ってきてからしか実行できないのだ。

>>920
じゃ、用途はゲームと言うことで。

要するにシングルスレッドをSPE群に分割してやらせても意味が無い、
と言いたいんだな。

そりゃそうだ。

>>917
　　----------------------
　　まだ実機も無ければ、断片的な情報しか出ていないわけです。
　　出ている情報から推論する以外に方法は無いですよね？
　　----------------------
少なくとも、私わ過去の事実と各種学会、イベント、公式資料から外れた話わ書いていないす。

　　-----------------------
　　既に出ている情報で>>894-896を否定できる物が有るのなら下さい。
　　-----------------------
あなたの例え話よりマシなCELLのプログラミングモデルの解説わGDCで行われているす。
http://pc.watch.impress.co.jp/docs/2005/0310/kaigai165.htm
http://www.watch.impress.co.jp/game/docs/20050316/ps3.htm
等々

PPE は、ア店にAを50個、イ店にAを50個、ウ店にBを50個、エ店にBを50個・・・発送したい。

各SPEの秘書(DMA)はオーダーを聞いて、SPEにケーキを必要数作らせる。
ケーキを作ってる間に秘書は次のオーダーを聞いておく。
するとケーキが出来上がってくるので、秘書は指定された店に配送手続きを行う
と同時に、SPEに次のオーダーを知らせる。
配送手続きが終わったあと次のオーダーを聞いておく。

の繰り返しが、CELLで想定しているボトルネックを隠蔽したプログラミング手法だ。

>結局はPPEが頑張ることになるんだよ！
>と、言いたいわけです。
>SPEは断片的にしか使えないよ。残念ながら。
ようするに貴方の主張は、SPEなんか活用出来ないって事ですね。
コプロセッサという言葉の定義を示さないという事は、
なんとなくその言葉を持ち出してみたけど特に意味があるわけではなく、
「SPEは断片的にしか使えないよ」という事を言いたいってだけなのですね。

SPEは断片的にしか使えないというのは、実際どういう用途に使えないと考えてます？
貴方は同期メカニズムにこだわっているが、それは何か理由があるんですか？

俺からすると、ある程度の向き・不向きはあるとしても、
貴方ほど悲観的になるほど使いみちが限定的だとは思えない。
これは >>924 でMACオタさんが最後に引用してる
プログラミングモデルというのが理由です。

結局の所貴方が否定しているのは同期メカニズムとかではなく、
IBMの提唱するプログラミングモデルそのものなんですかね・・・。

>>921
例えばビー玉を１００００個転がすＡＩを考えますね。
これって、一見Cellの得意分野に見えますよね？

単純に説明するために、一回の処理で玉一個動かすとしますね。

で、ビー玉の進行方向や速度を計算するに当たって近隣の地形データや抵抗値が必要だと。
でも、地形データを取ってくるには秘書に動いてもらわないといけないのですよ。

で、「次はこれを転がせ」とかをＰＰＣが面倒を見なければいけない。

メインメモリに書き込みせずにこの有様です。
ビー球が通った跡は1mm地面がへこむとか(この場合、同期が必要になります)
SPEで実現するのが妥当だと思われますか？

SPEで処理するだろうと言われればそれまでです。
が、漏れなら全てPPEで処理します。

１００００個転がすＡＩって何だ?

>>925
大分とコモンセンスが出来上がってきました。
全ての処理は結果的にPPEが音頭をとらなければならないと言う所は賛同いただけるわけですよね。
あとはＰＰＥに処理を渡すオーバーヘッドしだいではPPEは自分でケーキを作成したほうが早い場合も有るとご理解いただけますよね？

＞いや、申し訳ないが漏れがBeの知識を１から付けるのは大変なので…

>>910で書いてあるとおり、自分じゃ勉強もできないし、最低限の検索する能力も
ないのに、Cellについてだけ、やたら脳内妄想をたれているわけだが。
Cellの知識もロクにないのに語るのはやめておけ。

つーか、Cell使ったアプリの設計を自分は出来ないと騒いでるだけだったか。
おまえさんにゃDPSも扱えないのだろうから、コボル以外の仕事、特に組み込みとか
そっちには行かない方がいいね。

>>924
マックおたさん
漏れの論に間違っている所が有るならば、具体的にご指摘いただけますか？
漏れの論とご指摘のソースと矛盾しているところが有りますか？

>>929
>あとはＰＰＥに処理を渡すオーバーヘッドしだいではPPEは自分でケーキを作成したほうが早い場合も有るとご理解いただけますよね？
意図的に効率の悪い実装をすれば PPE 自身がケーキ作った方が速い場合もあるってだけで、
普通に組めば処理性能の差で SPE で処理した方が速いと思うけど

今だ電波扱いだったとは…
正直、「駄目だこりゃ」派はもう少し多いと思っていました。
ちと辛い。

こいつ、自分じゃ資料とか理解できないから、煽りくれて、ここでお勉強してるだけだろ。
かまうなよ。どうせ、そのうちいなくなるだろ。

>とりあえず、 今だ電波扱いだったとは…
>正直、「駄目だこりゃ」派はもう少し多いと思っていました。
>ちと辛い。

貴方が電波かどうかと、Cellは駄目かどうかは別の軸にあるからですな。
Cellを駄目だと思う人でも貴方に同意できるかどうかは関係ない。
貴方自身が、今日までの議論を元に下されている評価ですから。

材料不足で判断保留ってなら分かるが、最初に定量的な説明もせず
否定的意見を出す場合、電波扱いされるのはしょうがないんじゃない?
俺は別にあなたを電波とは思ってないけど。

なんと言うか、Cellの資料を見て
「おお、こりゃすげーヽ(ﾟДﾟ)ﾉ」と思うか
「駄目だこりゃ('A`)」と思うかってのは結構センスに差が有ると思うの。
良くも悪くも。
やっぱ簡単には理解しあえないわけ。

ちょい前に田島陽子(売国奴)が
「少数意見の側に立つのは大変なのよ」と、言っていたが
何を言い出すんだこのクソ左翼は！と思ったけど
ちょっとその気持ちもわかる今日この頃。

ちょっと休憩するよ。

>>934
それよりあなたのCOBOLという高級言語を馬鹿にしてる態度にムカツク

＞SPEに処理を渡すオーバーヘッドしだいではPPEは自分でケーキを作成したほうが早い場合も有る
自分でいうとおり>>927の例だってこの見積もり次第じゃんか
常に同期を取っていなきゃならない例なら当たり前だし、万能じゃないから駄目だという極論は
非難されるだろ

俺の場合、まだ海のものとも山のものとも分からんのだし、
ただ単に様子見なんだが…

（つまり、諸手を挙げてマンせーでも、ダメだこりゃでもない。）

ただ、久多良木のことだからかなりハッタリ入っているとは思うが…

疑問が出るのも当然だってば。彼に取ってはクラスタ組んであっても
シングルコアなんだから。
>>776
>Cellに期待していた人は、PPEは制御で、あとは８本のSPEをいかに動かすか〜
>みたいなモデルを考えていたと思うんだけど…
>基本的にはシングルコアとして使わざるを得ない。
>>816
>Cellは個々に独立した簡素なCPU(SPEだ！)をグリッドしているCPUだと。

基本的な認識が違うからすれ違うのも当然でしょ。今の主張は複数の
コンピュータを繋いであっても、ユーザが操作しているものでしか
処理が出来ないと言っているに等しい。ワープロ使うのにクラスタ
作っても意味が無いのはあたりまえ。

根拠がおかしいからな。公式発表は都合のいいことで信じないというのがありえんわけ。
常識的なプログラマなら「使ってから」判断するわけで。

公式発表から見えてくるネックを指摘するならともかく、公式はウソだとまで言い切られたら
話にならん。　肯定派とか否定派とかも意味ないし。

>>938
今の段階では「おお、こりゃすげー」も「駄目だこりゃ」も同じセンスでは?
大抵の人は情報不足による判断保留状態と思う。単にあなたが否定的意見を
述べるので、じゃあその理由は何、って周りが突っ込みいれてるだけで。

少なくとも PPE に処理を渡すオーバヘッドがどのくらいなのか具体的数値で
説明できない限り、SPE が使い物にならないという証明は無理だと思うけど。

戻ってきた。

>公式発表から見えてくるネックを指摘するならともかく、公式はウソだとまで言い切られたら
>話にならん。　肯定派とか否定派とかも意味ないし。

漏れの何処が公式をウソ呼ばわりしていると？

>>944
漏れの主張は
「SPEが使い物になるのは極一部の処理だけ」
だよ。かなり違う。

>>942
>ワープロ使うのにクラスタ作っても意味が無いのはあたりまえ。

ゲームを作るのにクラスタ作るのは当たり前なのかしら？

>>934
悪いイメージが有るならば謝る。
けど、なんだか漏れのことがコボラーで通ってしまったんだよ。
知らんがな。(´･ω･｀)

CellでSPE群に並列動作を巧くスケジューリングするには
プログラマ、ライブラリ、コンパイラ、OS
のうちどれが比重的に大事だと思う？

for(;;)って感じだな・・・。
自分に都合の悪い意見には全く耳を貸さないし。
どうせ、Cellスレも、新しい発表が出るまでは
何のネタもないからある程度仕方ないけど、
餌与えない方がよさそうだ。

とりあえず今までのレスを読み返してくれとしか言いようがない。
残念ながら時間の無駄としか言いようが無い。

>>946
じゃあ言い方変えよう。

少なくとも PPE に処理を渡すオーバヘッドがどのくらいなのか具体的数値で
説明できない限り、SPEが使い物になるのは極一部の処理だけという証明は
無理だと思うけど。

>>927

何を言いたいのかさっぱり分からん、っつーか何も言ってないように
見える。

どうやら、SPEがPPEと互換性のある同期手段を持ってるらしい、とか
DMA経由でPPEと同じメモリ空間を触れるらしい、ってのはこれまでに
上がってる資料で分かった。

要するに、ユーザレベルの並列プログラミングに関してSPEはPPEと
機能的には同じことが出来るらしいってことだよね？

となると具体的な事例でSPEが使う方が性能が高いのか、PPEを使う
方が性能が高いのかってのは、同期処理のレイテンシ等のパフォー
マンス特性が次第ってことだよね？で、それは公になってはいない、と。

> SPEで実現するのが妥当だと思われますか？
>
> SPEで処理するだろうと言われればそれまでです。
> が、漏れなら全てPPEで処理します。

根拠が見当たらない断定口調。コボラー(2)は、「SPEはコプロ」という
結論を自分の中で出してから議論してるように見えるぞ。

少なくとも頂点演算に関しては既にビデオカードでは
プログラマブルなSIMDユニットを6並列とかで
普通に動かしてるから特に問題無いだろうな。

Cellプロセッサってどうよ？SPE*2
http://pc7.2ch.net/test/read.cgi/jisaku/1111240473/

次スレ立ててみました。
なんかどっと疲れたけど・・・。

>>927
それおかしい。
テーブルでもってりゃいいだろ。

シーケンシャルにアクセスできるしどんなクソ実装を考えてるのやら。

ちみら、マジで宗教か？と思うくらいに妄信しているのな。
>>922で引っ張ってきたところがどれほど致命的な意味を持つのかマジで解らないの？？

まぁいいや。
気長に行くよ。
否定的な奴もいないと盛り上がらないだろうしね。

>>927
を読むと、コボラーを詐称する人の主張は、
1) Itanium2やPower5クラスタ系スパコンが不得手で
　地球シミュレータやCRAYが得意な類の計算は
　cellも苦手だろう。

という当り前の推測を土台に、

2) 殆どの場合はSPEがストールするだのcellが使い
　ものにならない

という激しく飛躍した結論に到達する所が説明不足だ。
詐称氏は 1) が解ってもらえていないと思いたいようだが、
問題は 1) と 2) の間の論理の飛躍に説明が無い事だ。

と思ったよ。

>>958
ごめん、地球シミュレータとか使ったことが無いので解らない。
どちらかと言うとSPEはストールを避けるために、外部からかなり独立した。
独立しているので外部との連携は激しく苦手だ。
と、言うこと。

>>959
いや、あなたの主張する結論「外部との連携が激しく苦手」については
分かったから、PPE 単独で処理する方がましなくらい連携が苦手で
ある、ということを数値出して説明してよ。

少なくとも俺は、それを説明してもらえない限り、
>>922で引っ張ってきたところがどれほど致命的な意味を持つのかマジで解らないの？？
はマジで解りません。よろしくお願いします。

>>960
ごめん、無理。
なぜ無理かと言うと、実機も無ければ詳細も発表されてないから。
逆に貴方もCellに仕事を振ったほうが早いと数値を使って証明出来ないでしょ？
どうしようもない。

>>961
俺のスタンスは、材料少ないから判断保留、ですよ。

当然、あなたの主張する結論は可能性としてはないわけではないので、
単に懸念として表明するなら理解できますが、数値挙げて説明が
出来ないのに PPE 単独で処理した方が速いって結論できるのは何故?

>>960 後半

例えばPPEメモリ上の足し算
a=b+c;
これをSPEにもって行った場合にどんな修正をしなければいけないか考えてみてくれ。
初めからカプセル化を考えて書け？
じゃ、カプセルが戻ってきたら誰が面倒を見るんだと。

ＰＰＥがＳＰＥ１〜８に処理用コードを送り込む。
ＳＰＥ１がメインメモリからデータを取得する。ＳＰＥ１は獲得したデータをＳＰＥ２にも送る。
ＳＰＥ２はＳＰＥ１からデータを取得する。ＳＰＥ２はＳＰＥ３にも（略）。

こうすれば読み出し帯域を節約しながら処理ができる。用途はレイトレ、物理エンジンなどの比較データ取得。
他にもいろいろ考えられるな。頂点計算や、圧縮したテクスチャの展開、ソフトにより生成、曲面データのポリゴン化、テッセレーション。

ＤＭＡＤＭＡと大騒ぎしてるが、どこに繋がっているかまったく理解してないのが笑える。
内部バスは４本でさらにパケットが複数持てるので、ＰＰＥのＬ２キャッシュやＳＰＥ１〜８のLS、メインメモリ、外部I/O、GPUの混載メモリ
へ並列してアクセスできる。

なんにも考えなくてもPPE単体よりパフォーマンスはデマス。

>>964
漏れがSPEを全否定しているように思っているならばそれは違う。
ご指摘の用途ではSPEは大活躍するだろう
だがそれら以外の用途ではどうだ？と、いう話。

>>965
加えて言うと、それらの処理ってnVidiaの領域が結構あるのでは？

>>964
あ、あと…

>ＤＭＡＤＭＡと大騒ぎしてるが、どこに繋がっているかまったく理解してないのが笑える。
>内部バスは４本でさらにパケットが複数持てるので、ＰＰＥのＬ２キャッシュやＳＰＥ１〜８のLS、メインメモリ、外部I/O、GPUの混載メモリ
>へ並列してアクセスできる。

初めて知りました。良かったらソースpls

>>963
何が言いたいのかわからないんですが。
AoS/SoA の話をしたいの?

全部妄想で、Cellはショボイです。ソースもありません。

SPEを使いこなすにはセンスが必要。
でアホなコーディングをするとPPEへの負荷がボトルネックになる。
こんな感じかな。

>>968
いや、単にそんな仕事はSPEに持っていかない。だってナンセンスでしょ？
と、言いたかっただけ。
じゃ、どんな処理を持って行けるのか〜と、つなげたい訳。


>>969
漏れは出来る限りのソースは出しているつもりなんだけどなぁ。
漏れからしたら〜〜は出来て当たり前だろ！
って人こそソースを出してほしいよ。

このお方のファビョり具合は>>938で察してあげてください。

>>971
>じゃ、どんな処理を持って行けるのか〜と、つなげたい訳。

じゃあ、どうぞ繋げた話を続けてください。
あと、あなたの言う SPE が大活躍する以外の用途って何ですか?

964が出てきてくれなくてかなり寂しい。
964と漏れは対立しているようでまったく対立していないから。
まぁ、それが解ったから出てこないんだろうけど。

>>973
>じゃあ、どうぞ繋げた話を続けてください。

漏れ一人では難しい。
そこら辺はバランス感覚なんだろう。
漏れの主張はづーっと変わっていない。
「ストリーム処理以外はPPE単独でやった方が早いんじゃないか？」


>あと、あなたの言う SPE が大活躍する以外の用途って何ですか?
ストリーム処理以外。
SPEは従来言われているストリーム処理よりは、まぁ、適用できる範囲が広がったと思う。

「以外」の一例くらいあげて見ろよ…
「以外」のほうが多いからあまり評価できないんだろ。

つか、ゲーム向きの処理でも連携が取れない（非常に苦労する）から駄目ぽ。
と言い出したのかと思ったら全然違ったのかと。

>>975
わかった。わかった。
例えば以前、誰かがあげていたＺソート(クイックソート)
これなんか無理をすればSPE複数本で処理できる。
無理をすればね。
でも、複数本を使ってもPPE一本のほうが早そうに思える。

>>976
もちろん、それがメイン。
でも、そんな大きな所を説明する能力が無いのよね。

で、ＺソートをSPEに回せばその間はPPEの手が開くからいいだろ！
と、言われるのならばまったくの正解。
でも、それってPPEが忙しいってのが前提条件だから。
その時点で、PPEには仕事がいっぱいあると理解しているから。

…ってあれ？全角の人の別キャラですか。
あぼーんしま。

>>977
問題はゲーム（とりあえずゲームのみ）が完成して全体でどういう結果が出るか、なわけだ、
過程か早かろうが遅かろうが、結果どうにでもなる部分ならどうだっていいってことでもある。

その上でCELLのなにが問題なのか、と。

誰だよ全角の人って。
しらんがな。(´･ω･｀)

>>977
そなの。で、ゲーム用として考えてもEEよりは良いだろうと。
実機がないと漏れも確認しようが無い。
つらいわぁ。(´･ω･｀)
なんで、こんなに激しく主張しているんだろう。

>>977
SPE で処理するなら Bitonic sort とかを使用するんじゃないか?
SPE に適さないアルゴリズムを利用して使えない、って主張するのは意味なくない?
まず前提として、ゲームでストリーム処理以外で演算性能が大量に必要なものってなに?

>>967
ttp://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/D9439D04EA9B080B87256FC00075CC2D/$file/MPR-Cell-details-article-021405.pdf

俺は964ではないが、例えばこの文書のMemory Flow Controller(MFC)ってのが、ここでいうDMAな。詳しくは中を読めばいいが、

>The MFC can also take the data from the SPE and load it directly into the Power core L2 cache as well.
MFCはまたSPEからデータを取り、それをPowerコアのＬ２キャッシュへと直にロードすることもできる。

また内部バス(EIB)には、LS(toSPE)x8、L2(toPPE)、MIC(toXDR)、BIC(toFlexIO)x2(GPUとIOPで2口)の、12ブロックがつながっているとNEにはあるな。

>>983
>まず前提として、ゲームでストリーム処理以外で演算性能が大量に必要なものってなに?
あんまり無いと思うなぁ。
無いから実態として、CellはPPE+コプロ８発だと。

>>984
ありがとう。
へー、メモリではなくてL2に繋がっているんだ。
そりゃそうか。じかにメモリでは整合性に無理があるか。

NEってのは聞いたことがあるな。
DMAの速度は4000クロックで256K〜ソースはNEって感じで。
NEにたどり着けなかったから持ち出していないけど。
見てみるよ。

>>985
>MIC(toXDR)

これがメインメモリだ。

となると実態としてスパコンにもレコーダーにも使われるんだから
どういう場合が「駄目だこりゃ」なんだ？

>>983
ごめん、Bitonic sortってどんなアルゴリズムか解らない。
良かったら解る場所をリンクして。
ぐぐった感じではマルチプロセッサ向けみたいだけど。

まぁ、どちらにしろソートはSPEの尤も苦手とする分野だと思うけど。
こんな事を言われると嫌かも知れないが、貴方は私とかなり近い位置に立ってきた。
CellはPPEがまずありきだと。

>>985
君の主張が、

>つか、ゲーム向きの処理でも連携が取れない（非常に苦労する）から駄目

であるのに、

>>まず前提として、ゲームでストリーム処理以外で演算性能が大量に必要なものってなに?
>あんまり無いと思うなぁ。

なのは矛盾してないか?
そもそも高い演算性能が必要ないゲームなら、わざわざ SPE を使う必要ないでしょ。

どうせそろそろ敗走だろ…

>>986
>MIC(toXDR)これがメインメモリだ。

…それはまた嫌な情報ですね。
下手をするとＬ２に入っているデータは手動で書き換えろと言うことかしら？
いや、流石にそれは無いか……

>987
…使われないと思う。

>>988
http://tpot.jpn.ph/t-pot/program/90_BitonicSort/index.html
http://www.iti.fh-flensburg.de/lang/algorithmen/sortieren/bitonic/bitonicen.htm

989
>そもそも高い演算性能が必要ないゲームなら、わざわざ SPE を使う必要ないでしょ。

そう言われましても…
SONY様が世代交代と言われますので、ええ。

>>991
>…それはまた嫌な情報ですね。
>下手をするとＬ２に入っているデータは手動で書き換えろと言うことかしら？
>いや、流石にそれは無いか……

いや、単純にキャッシュを汚染しないためだと思うんだが…。

>>993
言ってるからなんだんだよ…ホントに頭悪いな。

>>993
>そう言われましても…
>SONY様が世代交代と言われますので、ええ。

次世代ゲーム→高い演算性能→ストリーム処理→CELLが最適

で何が問題?

>>992
了解。ちょっと勉強します。

>>994
でもちょっと匂わないですか？
普通ならメモリに書いてL2を捨てるか、L2に書いてメモリはキャッシュに任せて終了にしたいと思いませんか？

>>998
いや逆に物理的に片方にしか接続しない事にするメリットがわからない。
ＰＰＵのＬ２にアクセスしたい時、したくない時それぞれ両方当然あるわけで。

で後は次のスレにな。

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。