元スレcellプログラミングしちゃいなよ3

cell覧 / PC版 /

みんなの評価 : ☆

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

51 = :

>>49
CUDAでいいんじゃね。

52 = :

>>51
> >>49
> CUDAでいいんじゃね。

「まっとうなC/C++」というのはCUDAへの皮肉だよw
Cellの方がはるかに作りやすい。
まぁ作りやすい以上の動機があるからCUDAが使われているわけだけど。

53 = :

三角関数も全く使えなくても、最適化が馬鹿でも、メモリ転送命令が低レベルでしか実装されていなくても、
それでもCellの方がはるかに作りやすいんですね、判ります。

54 = :

超越関数使えるのは便利だわな。
それ以外のツッコミは的外れ。

55 = :

超越関数なんて（細かい注文付けなきゃ）簡単に実装できるだろ？
何が問題なんだ？

56 = :

そりゃハードで超越関数の演算器持ってくれてた方がうれしいだろ。

59 = :

>>52
LSの容量制限でC++はやりにくかろう。結果的にCellもCUDAもそんなに変わらんと思うが。

60 = :

>>59
そういうことはどっちもやってみてから言ってくれ。

61 = :

どっちもCとちょっとの拡張で書ける程度だからねえ。書くだけならどっちもそこまで大差ないさ。
問題は最適化の段階だな。でも、これもコツを覚えて、そこそこの最適化でいいんならそんなには苦労しないと思う。
個人的な感想では、CUDAのメモリ周りの最適化がちょっと難ありか。Cellは最初からアラインメントとらないとそもそも
DMA転送できないようになっているから、あんまり考える必要ないが、CUDAの場合は、スレッドごとのDRAMへのアクセスパターンを
考えないと駄目というのが、う～ん。あとshared memoryのバンクコンフリクトを考えないと、とんでもないことに
なるときがある。ここらへんを、コンパイラかハードでなんとかしてくれるといんだけど。

63 = :

ググってたらこんなんめっけた

http://www.ibm.com/developerworks/jp/power/library/j_pa-asmvis/
第 1 回 asmVis を試してみよう
http://www.ibm.com/developerworks/jp/power/library/j_pa-asmvis2/
第 2 回パイプラインを最適化する

66 = :

いくらくらいになるんだ？

70 = :

>>68
それ何時出るんだ？
何プロセスで作ったら現実的なんだよ。
んな金があったら、拡張ボードを出すか、現状のアレな点を修正した
マイナーアップバージョン出した方が良いと思うんだが。

71 = :

拡張ボードってなんだ？
あれな点とは？

72 = :

>>70
微細化が進んだら規模を拡大するのは当たり前の話。サーバ用のCPUなんだから。

それに従来のCellの改良版なら、既に製品化されてるよ。

73 = :

>>68が出たらPS3みたいに不良コアをいくらか殺してくれて構わないから安く手に入らないかなあ。

74 = :

ああ、初代 Cell.B.E は 90nm だったのか。
だったら、4倍増(+LS増量)+αならありえる話か。ごめん。

どちらにしろ、PS3 限定状態じゃ流行らんだろな。
Atom + GeForce の方がやりやすそう。

75 = :

そりゃAtomの方が数は出るだろうけど、そもそも競合してないだろ。

http://www-06.ibm.com/systems/jp/bladecenter/hardware/qs22/

76 = :

Cellの将来はSonyとIBMと東芝がそれぞれ違う分野での使い方を想定し
異なる開発計画を持ってるから、「どの会社の計画なのか？」を
指定しないと話がスレ違いしまくりなんだよな。

Sony:ゲーム機（PS3及びその後継）
東芝：家電（画像処理）＆ノートPC用コプロセッサ（SpursEngine）
IBM：ブレードサーバー＆HPC用CPU

78 = :

Cell触ってみたいな
仕事では絶対やだけど

79 = :

>>78
仕事でSuperEngine触るかもしれん

81 = :

helloworldプログラムを作ったのですが、実行させると。
spu_create(): Invalid argument
spe_context_create: Bad addressとでます。
プログラムソースはfixstarsのチュートリアルどおりで、
PS3にはFedora7、SDKは3.0を導入しました。
ここの>>20さんの質問とほぼかぶっているのはわかるのですが、解決策がわかりません。
>>24さんのいう、バイナリのファイルが違っている、もしくは作られていない場合はどうしたらよろしいのでしょうか？

84 = :

>>81
fixstarsのチュートリアルの3.2章にあるソース（PPE/SPE用）をコンパイルしたということですよね。
私の環境では、Fedora7 + SDK3(厳密には3.0.0.3ですが関係ないでしょう）、で問題なく実行できます。

PS3 linux上でmountを実行した際に、spufsはマウントされていますか？
Linux環境周りの問題のような気がします。

85 = :

GT200とかLarrabeeとかのニュースもひと段落して、最近、新しい話がなくて退屈だ。
そろそろ、つぎのCellの話がでてきていいはずだよな。

86 = :

初代Cellは出たころは、9コアをいきなり実現して、業界にそれなりのインパクト、影響を与えたと思う。

次のCellは2010年後半で36コアだけど、どうなるだろうか。

さすがに32個もSPEがあると、本質的に今までと変わってくることが出てくる。

まず、一番問題なのはメモリの帯域だろう。現状でも帯域は演算に追いついていないが、
そこまで厳しい要求があるアプリケーションばかりでないので、実用には問題ない。
しかし、次のCellではコア数増で、帯域不足がより問題になるんじゃないだろうか。

IBMはもちろんそこら辺は考えた上で設計してるから、解決してるのだろう。その解決の
仕方がどうやっているのかが聞いてみたい。

次に、性能のスケーラビリティは32SPEでも問題なく保てるのかどうかだ。
これはメモリの話とも関係してくることではあるけど。初代Cellでは8コアで
ほぼリニアにスケールするという話がよく聞かれ、Cellの一つの売りになっていた。
2Cellで16SPEでもスケールするなんて話もあったような気がするが、次のCellでは
どうだろうか。

これが、32SPEくらいまでだったらスケールしたから、32SPEに設計しました
とかっていうのか、もっと100くらいまでいけることを確認しているのか、20個くらいが
限界で、あとは別用途で同時実行してくださいっていうのか、非常に重要だ。

Cellのスケーラビリティがよいというのは、他の半導体メーカーも注目しているはずで、
30個ぐらいでも性能でるめどがあるとなったら、他も真似して追従したくてしょうがないだろう。
8コアくらいまでが実用の上限なんて話もあるから、ここら辺の見極めをしたいはずだ。
まあ、アプリケーションによるけど。でもMARSが32SPEで効果的に働くってなったら、ちょっと
いいんじゃないだろうか？

87 = :

このCellのスケール性がLSのコヒーレンシを考える必要がないことが本質だったら、
次のCell、その次のCell(120コアくらい?)で、その効果が指数関数的に出てくるはず。
そうすると、LSの再評価みたいなのが起きてくるんじゃないだろうか。
このLSに相当するGPUのshared memoryはその先取りかもしれないし、もしくは
メニーコアの必然として同じアーキテクチャにたどりついたといえるのかもしれない？
まあ、スクラッチパッドなんて昔からあったから、そんなに偉いもんかわからないけど。

LSといえば、プログラマはみんな容量を増えることを、次のCellでは期待しているだろう。
Cellのスピードチャレンジで今年優勝した人は、LSの容量が本質的に計算の高速化
と関係するようなことをいってた。プログラムが楽とかいうことではなく。
LSの容量が許せば、SPEごとのローカリティの高いアルゴリズムに変更できることがある
というようなことらしい。

Cellがでてだいぶみなが人柱になることで、LSの容量はこれくらいあるべきというのが、
ユーザーからあがりつつある。LSの増加は当然トランジスタ予算を食うわけで、SPE数を増やす
ほうがいいのか、LSを増やすほうがいいのかの天秤につるして、次のLSの容量もきまるんだろう。

次世代のCellで面白いのは、競合するGPUが存在するなかでのデビューになり、Larrabeeとの競争は
激しいものになるだろうことだ。