IBM CellBE Workshop内容和重点

有幸参加了IBM的这个training，不过由于IBM自己管理的失误，很多人没能知道培训地点，在此特别鄙视一把。为期2天的training我参加了1天半，由2个IBM北京的讲师轮番上阵，嗯，分别是龚大和潘大。废话少说，切入正题。

首先是Cell的架构，应该已经很熟悉了，即使你不鸟IBM，PS3的硬件spec上也写着：PPE+8SPE，9个核，10个硬件thread。PPE是legacy Power5的架构，把它当Power5使没问题，完全兼容，有L1，L2两个cache。8个SPE，包含SPU向量处理器，为了向量处理和SIMD设计的，128个128bit通用寄存器（真多），dual issue channel，非常快，没有硬件cache设计。SPE还包含LS(256K)，用于SPU的本地存储器，latency也非常小、MFC用于DMA控制。EIB作为PPE和SPE之间的高速总线。

然后是开发环境。Cell SDK目前是2.1版本，跑在linux上。龚大说9月份会release 3.0，里面xlc的一些超强优化特性以及FDPR-Pro的SPE版本都会出现。好，不管以后的版本多么fancy，先来看手头有的东西： toolchain和compiler，当然是C/C++的，分别对应PPU的和SPU的有2份，所以会编译出两种executable格式。编译器可以用gcc或者IBM自己的xlc，据说xlc稍后的版本会有auto vectorization之类的功能粉墨登场，敬请期待。其他的工具链的东西可以参考普通x86上linux的那一套，基本用法当然是一模一样的。除此之外，IBM的工程师们还提供了很多profiling工具，比如静态的SPU timing工具，可以生成汇编代码和时序图、还有FDPR-Pro，对二进制代码进行无人工参与的优化，不过目前只对应PPU。为了方便大家发挥Cell的实力，IBM中国的lab也搞了一个叫ALF（Accelerated Library Framework）的东西，据说可以大大简化程序员拆分workload的工作，可以以脚本（还是GUI？忘记了）的方式定义workload，然后可以让程序自动优化处理时机，这个东西在培训中没有讲到，看来要好好关注一把。 最后么，还有些Eclipse插件，以及Cell的官方模拟器，这玩意儿将在运行时profiling中起到非常重大的作用，可以在里面看到每个cycle、SPU执行状态以及CPI（Cycle Per Instruction，据说普通程序可以优化到1.0左右，变态计算可以到0.6-0.7）和miss branching、dural issue rate等重要profiling数据，但缺点就是太慢，我在IBM的教室里，P4的老机器，跑win2k，再跑vmware上的fc6，再在fc6里跑simulator，又起来一个linux，即使是fast mode，模拟器工作的都很慢，如果是cycle mode，据说5秒钟的程序可以跑上4个小时。

以上就是IBM目前能提供给Cell开发者的一些东西，当然也可以去alphaworks多逛逛，看看有什么新货。

接下来说说如何使Cell变得更强。基本上，PPE会作为一个程序协调者的身份，用来调度所有SPE的工作、准备SPE的数据等等。而大量的数据密集的计算将落在这8个SPU的身上。SPU不要看它小，小也是小强，前面说了，是个高速向量机，所有的指令都是向量指令，即使是标量的计算也要转换到向量指令做。想起什么来了？GPU是吧。我个人感觉Cell的位置是在传统CPU和GPU之间，对pipelining的要求没那么变态，也不会有什么shader标准来让你束手束脚的做GP，但是又拥有general processor不具备的变态的向量处理能力，比较灵活，但效率可能没有GPU这么高，毕竟人家太专业了（PS3上folding at home还是比不过GPU的版本，但是比PC CPU版本要强多了）。哦，说远了。话说要让SPU发挥能力，主要看2方面。一是PPE能不能对SPE进行有效通信，二是SPE如何利用向量指令并优化自己的算法。那么基本上这俩都是巨大的命题。以下简要谈谈：

PPE和SPE之间通信主要3种方式：mailbox，signal，DMA。感觉mailbox和singal有点类似，都像是信号量一类的同步对象，不过是硬件级的。那么既然分这2个东西，那么一定是有不同的用途，这点需要稍后再作了解。DMA就很直观了，有了mailbox和signal做同步，那么DMA就可以放心的进行数据传输了，由于SPU只能对LS进行操作，所以会有大量的代码涉及到同步和DMA。

至于代码向量化，IBM的best practice是，如果对Cell和待实现的算法不熟悉的话，建议先在PPE上做scalar的版本，然后可以一步步移植到SPE上，比如先做内存对齐，再将scalar操作变为向量操作，最后审查算法的数据无关性，是否可以并行操作，以及可否分开到其他SPE上去完成。当然如果是Cell大师的话，直接写就可以了，不过貌似大师还没有生出来。Rapidmind也提供了很high level的解决方案，号称不用考虑硬件架构来写多核程序，不过貌似IBM的人不鸟之，还是觉得自家的ALF爽。不过IBM也承认这是个很大的问题，也不是一朝一夕可以解决的（Free lunch is over）。

那么以上基本就是第一天的内容，第二天就去了个上午，不过software programming model确实值得一听。这里就列举了几个有用的、常用的编程模型。比如streaming，几个SPU并行处理无关的数据，这在单个SPU处理能力足够的情况下较多采用、pipelining，几个SPU串行处理相关数据，但是难以作load balancing，在数据相关性大，以及单个SPU处理能力不足的情况下可以考虑。还有executable或者data超出LS的256K限制范围后，是用手动DMA，还是overlay程序段，或者采用software cache library来透明化LS和MM之间的隔阂。手动控制的DMA较适合data coherency较强的情况，若程序员知道一块大的block数据，那么最好使用这种方法。而software cache适合程序员需要random access大量MM数据的时候，而他对于数据coherency一无所知时，software cache可以提供较好的cache支持，因为SPE是没有硬件cache设计的。而一旦你的code size超出了LS的范围，就必须使用overlay来解决难题了，通过linker script来定义overlay的区域，但无须该动源码，而且不用担心会意外覆盖了程序空间。还有一些其他的model，比如kernel管理的SPU线程，离地球太远了（但好像VxWorks在做），不过自己管理SPU做cooperative multitask还是有实际应用价值的。

其他的还讲了SPU static timing的用法，生成的文件可以清楚的知道静态时序。以及通过模拟器动态运行，获得实际运行数据，除了太慢，都很好用。

最后回公司了，错过了他们一个mpeg2->H.264的实时转码的流媒体系统优化实例，可惜啊。买个PS3爽之。

几天后发现Wenle和潘大是同学……汗一个。

转载于:https://www.cnblogs.com/eygneph/archive/2007/07/20/825611.html