OpenGPU经典讨论（Zz）

文章被转载到了OpenGPU.org组织上面去，里面有很多高手对偶的这篇档案展开了讨论，无奈偶才疏学浅，不好发表什么，于是就默默的看着他们的言论学习强大. 现在整理一下他们的回帖，也是相当棒的资料和经验，让我受益匪浅. 原文地址：http://www.ispinel.com/2010/01/27/163 讨论内容： qiaojie：我相信异构平台会是未来并行计算的主流，不过感觉Cell的Local Memory是个比较失败的设计，直接导致了编程困难从而导致最终被抛弃，如果把Local Memory变成cache的话编程就简单多了。 cyj：我对GPGPU只有一知半解的理解，但是根据我的分析来看，CUDA中正是因为有的Shared Memory才能或得几十倍于CPU的加速比……，不知道这是不是也算作失败的设计？ qiaojie：其实NV也知道ShareMemory只是过渡方案，所以在设计Fermi的时候做了改进，可以让ShareMemory配置成Cache。Larrabee的话就更是直接的支持统一内存空间了，从编程角度上来说，我是更青睐Larrabee的，不过可惜Larrabee难产了。 maxiaohan：shared memory programming model是好东西。fermi允许cache/shared memory可配置不是说shared memory不好吧。 其实编程模型是shared memory抑或prefetch cache，都应该是application-oriented的吧。什么样的应用就用什么样的配置。 至少我用着nv的shared memory觉得还算开心。当然我也没写过有用的app… qiaojie：你写写玩具代码当然没觉得有什么了。但是开发商业程序的话问题就头大了，程序逻辑要根据具体硬件的profile来做优化，不要说A卡和N卡差别很大，N卡的1.0,2.0,3.0之间也有巨大的差异，要为各种硬件做不同的优化，这对开发人员来说就是一场噩梦。而Cell也有这样的问题，因为存储架构不一样，所以原来为通用CPU写的程序要移植到Cell上就必须重头写过，而且程序还更难写，开发难度太大了，大家自然就不喜欢用了，而且随着时间的推移，现在的通用CPU的运算能力也慢慢赶超Cell了，Cell就更没优势了。 ic.expert：所以我觉得在未来，JIT技术会大行其道，一种中间语言通过Runtime层来实时的编译成为最适合本地硬件的程序，Runtime也会配置硬件的Shared memory和cache的尺寸以及其他的芯片上的可重构单元！从而尽量发挥最大性能。当然，这东西也不是万能的，但至少可以为程序员隐藏一些架构的细节。只需要了解通用虚拟机的约束。 von_kypck：我觉得ic老大说的这种JIT只能在一定的局部起到作用，而算法和整个程序架构级的适应，JIT还是无能为力的，还是得靠人，新的编程模型以和理论去搞。 cell的例子说明：如果一种新的架构并不能为现有的技术积累提供一种低成本的迁移方式，是很难成功的。淫威大现在也碰到了一样的问题。 ic.expert：嗯，我非常同意这一点，语言太灵活会造成灾难，在语言上必要的约束是必需的~~~。所以我非常奇怪，cell为什么不用函数式编程(FPL)接口呢？如果用FPL的话，那就可以让runtime来管理Local Storage，程序员任务可以减轻很多。而且FPL在函数内部不能保存状态，非常适合任务拆分…… qiaojie：用FPL搞并行计算那不是更不靠谱么？ ic.expert：FPL是最好并行的，早期80年代的数据流机就是为了并行设计的，专门用来跑FPL。后来应为硬件CAM（context access memroy ,相联存储器）太贵，所以为传统处理器取代。 现在CUDA所推崇的流计算，如果把kernel当作FPL中一个函数的话，那么可以说CUDA具有粗粒度FPL的一些行为~~~ 其实想一般乱序执行CPU（比如现在的Intel CPU）中的out-of-order Kernel执行单元就可以看作一台最简易的FPL数据流机。他把指令相关转化成数据相关，从而让后面的指令得以超越前面的指令完成运算。我记得还有一篇论文专门讨论两者对比。回头我查一下，放上来！ qiaojie：我从不否认FPL对于并行的价值，但是要认识到FPL对于编写适合硬件特性的高性能程序是不完备的。FPL的历史比C还要悠久，每个研究软件的牛人都知道它的优点，但是对于高性能程序大家选择C而不是FPL。并行计算机的历史同FPL一样悠久，如果FPL能解决并行计算问题的话Intel早就好去死了，CUDA更不会出现了。 并行计算真正的困难不在于我们是否能够并行，而是同样一个并行算法相对于串行算法来说是否可以得到性价比更高的程序，是否可以提供足够的scalability。要让FPL成为并行计算的主流工具，有两条路，要么研发出适合FPL的硬件架构并且比现有的硬件更具性价比，要么编译技术有一个革命性突破，能够把FPL转换成适合当前硬件执行的高性能代码，目前这两条路都还没看到成功的端倪。所以现在谈FPL不过是拿30多年前的前人的研究经验出来炒冷饭而已，30年来我们在软件和硬件的架构上都没出现过革命性的变化，FPL能炒出什么新意来？ zhouhong：请教各位牛人一个为题，CELL处理器中的SPE的channel unit是做什么用的？ lidudu：赞同函数式语言对编程的不完备说。 函数式语法的一个问题就是，它做有些事情非常简洁有效，但另一些则非常难于表达。现代编程语言的潮流是在过程式语言里集成函数语法功能，如C#、C++0x都加入了lamda表达式，以此来互补。这样的结果是过程式和函数式的穿插，仍然难于自动完全并行化。但作为局部并行化，取决于其粒度，还是有效的，比如LINQ的并行实现后端PLINQ就是一个例子。 ic.expert：的确，qiaojie大牛说的也对。表达有些问题的确非常困难，是面向控制的程序。其实我并没有想让FPL包打一切，就是C、C++也不能包打天下~~，我只是说FPL在GPGPU Stream Processing领域还是可以有所建树的~ 希望大牛继续批评.