并行计算的挑战与OpenCL-优快云博客

不是每个程序员都关心并行计算，也难怪，这个世界充斥着大量不可并行的01，这苦了HPC的程序员，如果你的公司很忧伤的裁了你，你会像我这样很忧伤的学Java么？

说Cell B.E死了这句话不知道对不对，最起码IBM裁了这个部门，人们纷纷跑去做L2 support或者有幸去做pNext去了。一直不太明白IBM为什么把Cell B.E死死的焊在blade上，而不是像Mercury那样做成PCIe的板子，实现一种廉价的加速方案，就像ClearSpeed干的那样。我更愿意相信，在程序员没有为并行计算做好准备的时候，在并行计算百花齐放的时候，IBM是不会为这种没有高利润的东西花一分钱的。

并行计算的问题，首先在于体系结构的多样化和标准的缺失。集群，MPP，CUDA，Brook+，Cell B.E，ClearSpeed，每个人都说自己多牛，每个人都摆出巨高的加速比，但你能让程序员为每个平台都porting自己的程序么？MPP的消失，Beowulf的流行显然迎合了并行计算体系结构归一化的趋势。随着MPI和OpenMP成为集群系统事实上的标准，人们乐意把自己写好的程序放在更新一遍再一遍的集群硬件上，去继续享受免费的午餐。

Cell B.E显然断了这些程序员的念头，程序员需要去重新认识什么是PPE，什么是SPE，谁乐意这么干呢？IBM试图标准化一些自己的编程模型，ALF？可惜，没人捧场。Intel也在试图干类似的事情，TBB？不知道捧场的人有几个。Mercury做了自己的平台，好的地方是，这是个抽象硬件的平台，支持多种设备等等，捧场的人会比较多吧，但Mercury显然不能靠自己一力而标准化自己的平台，IBM不可能让他这么干，Intel不会，谁都不会。

于是Apple跳出来，推出了OpenCL，诸侯群家争相追捧。为什么是Apple，可能是他从没有自己的并行相关的东西出来吧。

OpenCL显然不仅仅面向GPGPU。它的更主要的目的是单节点（共享内存）中的异构并行环境。不可否认，MPI+OpenMP是现有Beowulf的流行方式，但这种模式对现有节点的加速技术显然准备不够。OpenCL首先能够瞄准GPGPU，推出标准化的接口，然后再屏蔽其他加速器，例如Cell B.E，例如ClearSpeed的技术细节，完成Mercury想做但做不了的事情。最后，MPI+OpenCL指日可待。

在单节点环境中并行的标准化是任何人都希望看到的事情。尤其对于我们程序员，掌握了OpenCL意味着掌握了所有异构并行环境，何乐而不为？有点时间大家看看孩子不比coding强啊。而所有硬件厂商如果能够在设计之初考虑到OpenCL spec，这显然又是一个大同世界。程序员的素质可能由此得以培养，这个时候IBM再推类Cell B.E的产品，估计就没那么多人被裁了吧，呵呵。