G80与PS3的RSX和XO的C1的数据图！

Eji

原帖由 complexmind 于 2006-11-18 13:35 发表
累死程序员是SONY的一贯作风呢！

话说回来，连第一批拿到刀板的人都只能有限度的乐观，估计就只是给IBM面子了
原文：replacing pointer deferences with DMA is usually slow ?So it is。
强过compiler的程序员 ...

並非"累死programmer"是SONY的一貫作風，實際上PS當初就是library齊全。
但是當時很多廠商都和SONY要求要越過library控制硬體，所以PS2初期的確也給廠商自由控制硬體，
雖然這並不能當library缺乏的理由。

強過compiler的programmer不會多，但是這比較和程式的規模相關。
人力靠assember在小規模下可以寫出很精巧的程式，但是如果把用C coding出來的東西disassember的話，
通常會出現令人匪夷所思的code，而且效率常比人力好。

但是，這同樣並不能當成Cell 必然xxx的理由。
其實說起來Itantium和Cell這種multi-thread、multi-core的CPU都有其與過去趨勢不同的前進方向，
所以初期遇到的抗力是必然的，programmer總是得接受free lunch is over的事實。

ayanamei

原帖由 Eji 于 2006-11-18 16:37 发表


並非"累死programmer"是SONY的一貫作風，實際上PS當初就是library齊全。
但是當時很多廠商都和SONY要求要越過library控制硬體，所以PS2初期的確也給廠商自由控制硬體，
雖然這並不能當library缺 ...

关键是PS3现在要和软件环境赛跑

Eji

原帖由 ayanamei 于 2006-11-18 16:39 发表

关键是PS3现在要和软件环境赛跑

我倒覺得還有和自己的價位賽跑。:p

hamasaki

少卖点，慢慢拖倒那几大件的成本降低...

SM5

原帖由 Eji 于 2006-11-18 08:55 发表


PPU我記得是Cache結構階層很多，所以cache頻寬很大(2TB/s相當，Ageia人員訪談透露)，
但是peak performance似乎只有30GFLOPs？(話說這個數據好像是ATI給的，我該信嗎)

有那么大的频宽吗？ 2TB/S    汗:funk:

Eji

原帖由 SM5 于 2006-11-18 19:11 发表


有那么大的频宽吗？ 2TB/S    汗:funk:

well，它對外終究是128bit GDDR3.... :)

aeondxf

原帖由 Eji 于 2006-11-12 14:12 发表


那個問題已經解決了。
說起來我剛好認識某位SXXA的林先生...(逃

別的不說，我是覺得PPE要跑compiler大概會蠻悲慘的....
Road runner這種超級電腦，大概有不少機會跑到compiler，因為針對性咚愕年P係。 ...

这个……问了一下，据说是回避性解决，实际上可用的还是4个……

Eji

原帖由 aeondxf 于
2006-11-26 22:38 发表

这个……问了一下，据说是回避性
解决，实际上可用的还是4个……

唔，有更詳細的資訊嗎? 我想再問
問。 就我所知，只有工作特徵問
題。

aeondxf

原帖由 Eji 于 2006-11-26 23:35 发表

唔，有更詳細的資訊嗎? 我想再問
問。 就我所知，只有工作特徵問
題。

还是将原话直接转过来好了:理论6个……但还是4个，所谓解决4+的问题并非完全解决，而是回避性解决，可令SPE在0值下选择性效能屏蔽解决了4+效率狂降的问题，令可动用SPE理论可达6，但是实际有效仍然是4。PS3需要修补的地方还很多，如果在明年一季度前仍然和现在这样，那么画面上将被360与Vista的并行游戏拉开更大差距。

另外问一下EJI大,现在网上的R600截图都是假的么?

aeondxf

按照他的说法是PS3上CELL的状况^_^

Eji

原帖由 RacingPHT 于
2006-11-27 10:08 发表

嗯, 这是一个什么人?
是VF5的个体状况?

老實說看不懂(汗
不過應該是指當初本田雅一在自己
的blog提到的"developer自行將工作
在三種thread中選擇一種，之後
compiler會自動指定給SPE"。在這
個分配過程的效率問題。

畢竟，如果是硬體問題，也不必改
了。(汗

ayanamei

原帖由 RacingPHT 于 2006-11-27 17:20 发表
为什么CELL不做成8个SPE共享2M LS + 少量L/S buffer的结构呢？我肯定那样的内存管理要容易得多。LS的带宽如果做成512bit, 就可以提供204G/s的吞吐量。每个SPE还是做16byte每周期。(在

貌似CELL的设计就是 可以灵活拓展的结构
SPE灵活的配对 如"cell"其名  
如果LS做到一起 那么就很难做到灵活的consoles
MFC EIB的意义同样也就没有了

ayanamei

原帖由 RacingPHT 于 2006-11-27 17:25 发表
一个PPE带几十几百个SPE的情况是什么结果呢？。。

PPE也未必只能有一个阿。。。=.=
但是据说EIB拥有对SPE编号识别的能力，而且这个编号可以达到32bit
看来IBM是有很疯狂的想法

ayanamei

据说现在256K 这个规模都是几次扩大以后的规模了
或许工艺成熟以后的65nm cell可能会搭载更高容量的LS

ayanamei

原帖由 RacingPHT 于 2006-11-27 17:33 发表
SPU当然是有固定编号的. 32bit不代表要上4G个SPE吧。
大概SPU对访存延迟的确定性相当敏感，所以一定要采用分开的LS吧。不过如果SPU采用SMT的设计, 就可以避免这个问题。。扯远了。
IBM自然有他们的考虑，不过 ...

还有
EBI配合MFC可以操控非常高数量的SPE
如果是在大规模的集群运算上  可以编号异地的SPE，而且可以根据已知的延迟 安排各个SPE的工作
这样集群运算的效率会不会更高呢
CELL发布的时候是有过类似的概念的

一个主程序可以直接抓到client的运算资源的话 协调起来应该会容易很多吧

[ 本帖最后由 ayanamei 于 2006-11-27 17:44 编辑 ]