GPU计算的十大质疑—GPU计算再思考

http://blog.csdn.NET/babyfacer/article/details/6902985

原文链接：http://www.hpcwire.com/hpcwire/2011-06-09/top_10_objections_to_gpu_computing_reconsidered.html
作者：Dr. Vincent Natoli, Stone Ridge Technology （http://www.stoneridgetechnology.com/ ）
译者：陈晓炜（转载请注明出处 http://blog.csdn.net/babyfacer/article/details/6902985）

译者注：根据文章内容，将原文标题（Top 10 Objections to GPU Computing Reconsidered）稍作意译。
文中有些地方并非直译，重在顺畅的表达和实质内容的理解。本人翻译功力一般，若有不足/错误之处，请不吝赐教。

近几年GPU的出现，对高性能计算领域发展可谓是起到了不可估量的推动作用。GPU计算对性能的数量级提高使得它获得了比传统解决方案更多的成功案例。

大量科技工作者热爱、追捧或使用GPU技术，但同时还有更多的人因为各种原因坐视不理。本篇针对后者，总结了一些对GPU计算领域最常见的问题、顾虑或主观臆断等。

接下来的内容将尝试解决这些质疑，通过GPU计算的进展和我们对未来科技发展的预测来重新思考这些问题。当然，GPGPU不是所有HPC应用的终极解决方案，但是很多人也会发现这项技术在性价比上的优势，以及它能在诸多领域的成功应用，比如地震图像学、电磁学、分子动力学、金融定价估价模型、医疗图像领域等等。

1. 我不想重写我的代码，或重新学门语言

如果要使用GPU，重写代码是肯定的。其实你将目前的串行程序编写为并行执行的CPU程序也是需要重写代码的。关键的问题是你的目标平台到底是什么。如果目标是多核CPU，那么它的并行处理建立在对进程（process）、线程（thread）和寄存器（register）级别的三层模型处理上，你需要用到的是MPI、OpenMP/pthreads 和 SSE/AVX 扩展等。其实用CUDA为GPU编程并没有比上面的处理更困难，优势还体现在它对计算限制（compute-bound）和内存限制（memory-bound）上都能有显著的性能提升，我们待会将谈到。

如果你已经有了并行的代码，那你将其用GPU实现有何好处呢？针对代码的芯片级比较，计算上一般会有5到40倍的提高。这在采用了GPU的方案上能看到很多出版物予以佐证。在过去的几年，这些陆陆续续的比较结果是基于Intel和NVIDIA的产品。

CUDA是C程序的扩展，对于有经验的程序员来说很容易上手。现有的并行编程模型想实现百亿亿次（exascale）运算还不现实，但我相信最终的解决方案相比CPU并行处理方式而言，看上去应该更像CUDA并行模型。我之前说过，CUDA迫使程序员去思考如何将他们不可减少的并行处理问题对应到线程上，这是一个好的并行编程模型，可以让问题在单节点多GPU和多节点上都能得到较好的扩展性。

在这个方向上学术界已经有一些非常好的成绩，比如Global Memory for Accelerators (GMAC) ，商业界也有扩展性非常好的HUESPACE API（由挪威奥斯陆的一家公司HUE提供），还有他们的兄弟公司，专注在石油和天然气的GPU应用开发，Headwave公司。

2. 我不知道用了GPU计算能达到什么样的性能

HPC代码不是有计算能力限制（compute-bound）就是有内存限制（memory-bound）。对于compute-bound的代码，我们可以用NVIDIA Fermi M2090和Intel Westmere做个比较。Fermi有512个核，1.3GHz，而Westmere有6个核，3.4GHz。在核心赫兹上的比较，前者是后者的32倍。如果你的CPU代码可以有效地使用SSE指令的话，也许在CPU这边可以再提升4倍，那么前者还是后者的8倍（接近GFLOPS峰值的比例）

对于memory-bound的代码，GPU的内存带宽是177GB/秒，CPU为32GB/秒，前者是后者的5.5倍。这里前提是你的代码达到compute-bound，GPU性能会5倍于CPU（针对SSE指令高度优化过的代码），最高有20倍（对于某些特定代码）。如果你的代码是memory-bound，GPU大概会有5倍的性能提升（芯片对芯片的比较）。

当商讨并行解决方案时，考虑边际成本是有帮助的。

• 如果代码是memory-bound，你应该考虑用最便宜的选择来增加带宽，要么是加一张GPU卡，大约是每GB/秒需15美元；要么添加一个节点，名义成本大约是每GB/秒需80美元，后者方法还增加了计算能力和操作系统的负担。
• 如果代码是compute-bound，计算方法类似，可以得到Gigaflops的边际成本。
• 如果代码是compute-bound和memory-bound都存在，大多数代码，GPU在隐藏memory-bound延迟，提高compute-bound 方面表现较好。

3. PCIe带宽会严重影响我的性能

有人针对PCIe带宽限制来质疑GPU计算效能，这的确是因为计算密集（大计算量）的一个问题。计算密集（Computational intensity）有很多种定义，其中之一是用FLOPS，也就是每秒运算多少次浮点数操作。将每个数据传输到GPU板子让GPU运算，其中存在一个传输上的阈值。

比如，PCIe v2.0 x16 带宽大约是每秒6GB，在M2090板上填充6GB数据大约需要一秒钟，计算峰值可以达到665GFlops。M2090是个浮点数运算怪兽，每秒可以处理这么大的数据量。如果在这个例子中，你想让PCIe数据传输时间不超过计算时间的十分之一（也就是数据传输不要影响到计算），那么在数据每次就绪之前，M2090必须做成千上万次的浮点运算，所以必须尽可能快地去传输数据。

此外，CUDA允许PCIe数据传输采用异步重叠（asynchronous overlap）方式。灵活使用该方式可以在计算时隐藏部分或者全部的PCIe数据传输时间。成功案例有物理学中的Finite Difference Time Domain (FDTD)算法和分子动力学中的N2粒子与粒子交互等，都能显著做到数据重用和高计算密集度。

某些算法在GPU上并不是太有效，比如简单的向量积，计算量很小。如果问题需要在多个GPU上协同运算，那么要尽量减少数据传输的时间。

4. 如果解释Amdahl定律带来的启示？

Amdahl定律量化地揭示了一个事实：如果你打算对大段串行代码的一部分进行加速的话，不管你用什么方法，除非去加速提升最大的部分，否则不会有太大的提高。简单地说，一个程序中如果50%的处理都需要串行进行的话，speedup 只能提升2倍（不考虑事实上有多少线程可用）；如果程序的10%需要串行进行，speedup 最多能够提高近10倍。Amdahl定律同样量化了串行化的效率开销。在拥有10个处理器的系统中，程序如果有10%是串行化的，那么最多可以加速5.3倍（53％的使用率），在拥有100个处理器的系统中，这个数字可以达到9.2（9％的使用率）。这使得无效的CPU利用永远不可能到达10倍（参见链接：http://sesame.iteye.com/blog/428011）。

针对上述论断，对GPU并行性能提升最有效的反驳就是根据观察，现代计算机体系架构想要提高性能，必须将所有代码尽可能的做到大规模并行化，并且尽可能地去减少串行代码，不论是在CPU平台还是在GPU平台上。问题是，你是想在CPU上并行化你的代码呢，还是在GPU上？

5. 万一NVIDIA公司倒闭了怎么办？

HPC历史上有许多超级计算公司，致力将并行计算推上一个又一个新的台阶，比如Thinking Machines，Maspar，KSR，Mitrion等公司。它们付出的艰辛努力和公司的幕后功臣的创造性思维让我们对什么可行什么不可行有了深刻的理解。他们非常值得我们感谢和尊敬。

但是NVIDIA，并不是一家研究超级计算的公司。这个盈收近50亿美金的公司，大部分收入是来源于显卡和卖给PC游戏市场的嵌入式处理器。这种相对独立性对于HPC而言是优势，而且如果所有使用GPU的HPC全部消失，NVIDIA公司仍旧可以活得很好。只要有一帮重度游戏爱好者围绕在NVIDIA旁边就行。事实上，NVIDIA公司在市场上比那些HPC常青树公司更有竞争力，保险系数更高。

而且，NVIDIA公司发布了他的愿景和六年的科技发展蓝图，字里行间可以显示出他们想将GPU从传统的图形加速角色转移到计算机架构中心位置的的野心（BBF注，也就是想做CPU啦）。顺着这条路，他们会计划发布更加强劲的计算引擎。

（BBF注：其实这里也可以用OpenCL，毕竟是一个联盟，而且与CUDA类似，只不过目前还相当不成熟。）

6. GPU板不能针对我的问题提供足够使用的内存

对于M2090和M2070的GPU板，板上内存有每秒6GB的传输限制。这对于需要某些数据量超过内存限制的算法会出现问题，可以在单节点上用几张卡并行处理来解决问题。（作者用Dell C410 PCIe机器可以装16张NVIDIA的GPU卡举例，这里不细说了）

目前最多的问题是算法需要实质上的对大数组的随机访问，比如大哈希表或者其他需要随机数组查找等。现在的GPU板对于这些问题还未有一个有效的解决方案。但是内存越来越便宜，存储密度也越来越高，相信将来的GPU板会装载性价比更好的内存。

7. 我可以等更多核的CPU，或者Knights Corner计划

多核有助于解决 compute-bound 的应用，但是应该意识到，当更多的核被加到CPU中的同时，同样的事情也在GPU身上发生。比较一下CPU和GPU发展蓝图，可以看出他们在计算和带宽上的差距。这种情况还将继续下去。对于 bandwidth-bound 的问题，情况或许更差，因为加核比加带宽要显得更加容易。

Intel计划出Knights Corner，宣布了一年多，他们也意识到GPU是x86并行数据处理的竞争对手。有关Knights Corner的详情目前仍不得而知，我们估计有50个核，1.2GHz，每个核有512位向量处理单元，支持4个线程并行，是HPC的强劲对手。但是这个计划的开发模型、价格、公布日期和其他很多关键信息，到目前为止都是未知数。

坊间争论 Knights Corner 也许会成功，因为于x86架构统治着HPC计算领域。隐居HPC世界的科学家们需要寻找更广阔的市场来拓展高性能计算，图形图像也许是个选择，在这方面NVIDIA和AMD已经做的很不错了。

8. 我不喜欢专有的语言（proprietary languages）

专有语言这里指某种被某一机构所支持的语言。它可能会发展到一个未知的或者不希望去的方向，或者失去机构的技术支持。CUDA可以归为此类语言。不过使用CUDA的优点也是显而易见的：1. 它可以利用NVIDIA硬件独有的某些优化特性；2. 没有某一个委员会对蓝图发展做简单决策；3. 它能更快地支持新的NVIDIA硬件特性。

但是，如果专有语言在您的机构无法被采纳，也许OpenCL作为一个非专有语言进行开发，是一个绝佳的选择。OpenCL，被Apple、NVIDIA、AMD、Intel等诸多知名厂商支持，提供跨硬件平台的易用功能。我这里强调功能上易用，与此对应的是性能上的代价。相比CUDA内核，OpenCL内核显得相当简单，在主机端的设置和启动代码也有更多的不同之处。

9. 我在等CPU与GPU代码转换器这种魔术工具出现

对于这个，有个好消息，也有个坏消息。好消息是这种CPU到GPU的转换器已经有了，坏消息是它产生的代码和专家编写出来的代码，性能上无法相比。可以用The Portland Group (PGI) 的 PGI Workstation 和/或 CAPS HMPP workbench去测试一下。

10. 我有N个代码需要优化但是IT预算有限

说白了，这就是“要么不做，要么就彻底做到位”的尴尬。添加支持GPU的节点到有固定预算的机构基础设施中，需要在两个选项中做出选择，要么是更强大的异构GPU节点，要么就是不够强大的传统CPU节点。对于以后系统升级，从经济的角度来看，某些机构要么100%选择GPU节点，要么干脆不选择。这对于那些全年无休，存在市场竞争的商业机构中的集群更是如此。分析这种IT架构复杂调度系统，最坏的情况下，所有东西都需要CPU和GPU两个版本：集群管理脚本、调度、编译器、测试验证、应用程序代码等等。

大型商业机构采用技术都需要考虑投资回报率ROI。“要么不做，要么做到位”这个争论，表现出一些有远见、深思熟虑的机构对于用可量化的已知成本来面对科技转化所产生的未知成本时所面临的困境。最后这点和上面九点一样，在某些方面要么和投入相关（代码开发，人员技能，新硬件，再培训费用），要么和回报相关（性能，可扩展性，耗费能源）。

每个公司必须有它自己的ROI公式来处理上述问题。使用传统的财务分析，资本的投资必须要对股东有利，也要和公司其他方面的投资做比较（BBF注：这里翻译得比较简单，其实就是要周全考虑各方面的投入）。

总之，GPU计算在HPC市场上的持续投入，最近四年有了非常显著的收益。上述的十大质疑来源于个人和机构，他们都想解决上述问题。GPGPU并不是所有HPC问题的解决方案，但是不应该为错误的判断理由而错失能给性能上带来显著提高的技术。

最后，各个机构应该向GPU计算迈出一步，因为这不仅仅是今年的解决方案，而是一个深思熟虑后得到的策略。这个策略不仅解决了当前的成本问题，也是迈向未来架构、编程模型和实现百亿亿运算的最佳解决方案。