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

ayanamei

原帖由 RacingPHT 于 2006-11-27 17:44 发表
不过CELL的设计哲学是以ALU density为首要考虑, 我怀疑晶体管资源上来之后还是倾向增加SPE的数量, 而不是LS.

那就看256K LS带来的负面影响是什么程度了
这个IBM他们肯定会去权衡 选择最有效的方式

ayanamei

原帖由 RacingPHT 于 2006-11-27 17:49 发表


晕到. MFC怎么会去操控SPE呢.
EIB根本不是一个管理部件, MFC也不是. PPE做协调, SPU通过command list控制MFC, MFC从EIB从主内存网LS抓数据.
要协调, 只能是PPE做; 但是PPE只能有本地SPE的映射地址.

重复整理思路 表述一下
EIB只是一个高速的环路 但是可以动态编号SPE
MFC是一套指令系统
为SPU抓数据到LS

不知道在以后的给予CELL系统中会不会有CELL之间的并列
比如EIB之间的链接？？
然后通过EIB 链接大量的的SPE
让这些SPE在一个程序控制下并列工作
而且在MFC这套体系的基础上 可预测的延迟 就可以想办法回避掉
只要程序管理的过来
这样来提高这样的集群效率
就是PPE的应该是是也可以有延伸性
想象一下几个机架上的东西像是在同一个CPU一样在工作
貌似当时我理解的就是近似于这样的
反正听起来蛮疯狂的

基本上 貌似就是这么个一个概念

ayanamei

原帖由 RacingPHT 于 2006-11-27 18:23 发表
ayanamei应该增进一点对CELL的了解...
MFC本身就是异步的东西, 没有确定的延迟, 更没有推测延迟的能力.

我对CELL目前的认识
SPE就是用软件方式来在把数据从内存抓到LS里面 代替掉cache
这个个软件方式就是利用MFC 来控制这个过程的
具体操作 细节就没概念了
然后这个延迟是指从内存抓数据到LS的延迟
从抓主存的延迟情况是程序员可以预测的 那么更大的延迟也是可以预测的吧?
如果访问非片内异地资源 那么协调延迟更大的异地单元也是可行的吧?

当然可不可行应该更多是看软件

上面说的这个东西我是简单理解的 不敢保证正确  CELL的相关资料没看过 只有最早cho的文章中的那些东西
或许和实际的做法有出路  但是CELL瞄准了大型的计算系统这个是肯定的
偶倾向于相信这个说法 只是因为说IBM搞出这么套复杂的东西 应该不仅仅是为了个PS3不是么
:lol:
内行看门道 程序员可以接触到一些很具体的东西
外行就只有看热闹了

Eji

原帖由 ayanamei 于
2006-11-27 17:46 发表

那就看256K LS带来的负面影响是什
么程度了
这个IBM他们肯定会去权衡 选择最
有效的方式

就GameTomorrow當初的說法，是
從1cycle延遲的64KB，擴展為
有6cycles延遲的256KB，實際上仍
以64KB為單位分成四個區塊。

Eji

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

那個4G個SPE的部分，就我所知其
實是一種processer-in-memory的觀
念，所以理論上對應到的容量就變
成剛好可對應4G個資料長度32bit的
SPE，總合64bit?
SPE內部好像的確是dual-issue，可
以邊咚氵叞徇資料。
最後，Spe的號碼不是固定的，是
開機過程中賦與的，並且可以自
訂。

ifu

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

我对CELL目前的认识
SPE就是用软件方式来在把数据从内存抓到LS里面 代替掉cache
这个个软件方式就是利用MFC 来控制这个过程的
具体操作 细节就没概念了
然后这个延迟是指从内存抓数据到LS的延迟
从抓主 ...

这里cell资料比较多
http://www.power.org/resources/devcorner/cellcorner/
还有training可以科普一下：）
http://www.power.org/resources/d ... er/cellworkshop0606