实施并行编程的五大障碍

近期看见一篇来自Intel的很有意思的分析文章，作者提到在他向45名与会的各公司程序员/开发经理/战略师提问“什么是实施并行编程的最大障碍”时，下面五个因素被提及的次数最多：遗留代码(legacy code)、教育(education)、工具(tools)、对众核趋势的恐惧(fear of many cores)以及可维护性(maintainability)。文章虽然是一篇Intel Parallel Studio的软文，但是其中提及的这五大障碍却非常值得讨论，下面是我对这五大障碍的一些粗浅看法，希望能起到一个抛砖引玉的作用，欢迎大家给出你们的看法。

1. 遗留代码

众所周知，怎样把公司的那些遗留代码给并行化是一件非常困难的事情。100K~1000K的代码量都非常正常，而并行编程本身又是非常容易出错的，一大堆诸如data race, dependency, non-deterministic, memory consistency, dead lock, serialization bottleneck, thread safe等的问题随便哪一个拉出来都让人头大，更别说要高效可靠的并行化这些庞大的遗留代码了。更困难的是很多遗留代码还有编写者已经离职，文档注释不全等问题，这无疑是雪上加霜。从成本上来讲，如果能通过一些优秀的编译器(例如Intel的ICC)自动并行化一些遗留代码无疑是最省钱的，但是这种方法最大的缺陷就在于像Intel ICC这种自动型编译器能自动并行化的代码非常少，从而导致它能提供的性能优化非常有限，而且就算是真正能获得speedup的代码也有很多约束条件(例如loop的循环之间没有dependence，并且该loop应该是一个程序热点)。所以目前的现状就是大量的遗留代码并不能有效的被并行化，从商业的角度上来讲，如果能有一种解决方案能在短时间内快速可靠的通过实施并行化让遗留代码在多核平台上获得10%~30%的性能提升，那么它就已经能为公司节省大量成本了。

2. 教育

第二大的障碍可能就是程序员缺乏并行编程方面的教育了。其实并行编程已经有二三十年的历史，不过在多核CPU出现之前那些并行编程都是“专家”们的玩具。那时候的并行编程大都是跑在集群、大型机或者服务器上，通过MPI(message passing interface)或者SMP(对称多处理器，即一个主板上有多个单核CPU，属于shared memory model)来完成并行计算。Pthread标准是1995年建立的，之后出来了Windows版的Win32 thread，后来又出来了“编译指导”、面向data parallel模型的OpenMP(OpenMP 3.0加入了task parallel支持)，task parallel的鼻祖Cilk，Intel的Intel Thread Building Block(task parallel)，Java 1.5开始对多线程提供较好的支持(加入了Java Memory Model)，近几年随着GPU的发展，Nvidia又开始搞CUDA(data-parallel)，Apple一看不对，并行编程以后是主流啊，我得插一手，于是自己撑旗弄了个针对CPU和GPU混合编程的OpenCL，微软一看也坐不住了也要随着Visual Studio2010开始搞C#的并行库，马上C++0x也要加入多线程支持，甚至连老古董Erlang也因为天生支持并行被重新热炒，总之随着摩尔定律在串行世界的失效，整个业界都开始被迫往并行编程方向发展。

可是对程序员来说呢是什么情况呢？我们现在所接受的教育大都还是串行世界的那些算法和数据结构，高德纳在一篇访谈里说“在我看来，这种现象或多或少是由于硬件设计者已经无计可施了导致的，他们将Moore定律失效的责任推脱给软件开发者，而他们给我们的机器只是在某些指标上运行得更快了而已。如果多线程的想法被证明是失败的，我一点都不会感到惊讶……你听说过有多少程序员对这种未来一片光明的机器抱有强烈的兴趣？我几乎没有听说过，除了他们的诉苦。尽管我们学院那些搞硬件的家伙一直想让我相信我是错的”，可见硬件发展被迫向多核转移直接导致程序员们免费的午餐已经结束了。那么程序员现在受到良好的并行编程教育了吗？很显然，现在随便问一个普通的程序员：“你觉得并行编程容易么？”，十有八九会说“我觉得很难”。前一阵有人讨论服务器编程用多线程好还是多进程好？其实根本原因就在于哪怕多线程有性能优势，可是isolation的多进程模式能在programming productivity和performance之间找到比较好的折衷，所以国内很有服务器开发者都选择了多进程(例如云风)。从大趋势上来讲，不管是研究体系机构的，还是写OS/Compiler的，还是定义编程语言的，现在都在积极努力的为广大的程序员提供一个更容易使用的并行编程模型，Intel这几年不也在搞多核培训么，这都是好现象，但是，离真正的全民并行编程时代还有相当长的路要走。近几年的IT技术热门书单里面很少有并行编程的书籍就是个很好的写照。

3. 工具

工欲善其事，必先利其器。那么现阶段我们能用的，并且好用的并行编程工具有多少呢（欢迎大家补充）？

(1) IDE: Intel Parallel Studio，微软马上出来的VS2010算一个，Sun的Sun Studio(不知道它的未来如何，但是它本来就很小众)，Nvidia的CUDA平台什么的就先不算了
(2) Compiler: Intel的ICC(能自动并行化一些代码)，Nema Labs的FASThread(一套可以快速可靠的指导程序员实施并行化的解决方案，特别适合将遗留代码并行化)
(3) Performance Tuning: Intel Vtune Analyzer(综合性能分析)，Thread profiler，Acumem的Thread Spotter(针对多核Cache的性能分析和优化)
(4) Debugging: Petra的Jinx

总体上我个人觉得它们对程序员来说确实有用，但是前提条件是你要会用。这其实又跟第二点“教育”有很大关系了。

4. 对众核的恐惧

现在我们看到4核已经非常普遍了，等过几年那可就是8核，16核，32核了。怎样确保你的代码在核数倍增的趋势下仍能有很好的性能，很好的可伸缩性？这真的是个问题。我现在所做的研究就是多线程程序中锁竞争的性能分析，目的就是为了帮助程序员更好的解决由锁竞争造成的性能瓶颈。实际上，为了得到很好的可伸缩性，程序员需要往往需要使用并行友好的数据结构(例如concurrent hash map)，使用细粒度的锁甚至无锁编程，设计data parallel的算法，性能调优(例如典型的false sharing问题)等等等等，这其中每一项都是不小的挑战。我曾经翻译过的一篇文章对设计多线程程序提供了一些有用的建议。

5. 可维护性

毫无疑问，我们希望并行代码能够与现存的runtime系统、build系统以及其他现有代码一起正确的工作，我们更希望这些并行代码易于理解、便于维护并且有较长的生命周期。可是现阶段真正掌握并行编程的程序员少之又少，而且并行编程又是这么困难，哪怕你对这些并行代码只是做一些小小的改动都很有可能导致新的bug，新的性能瓶颈，那真的是一件非常痛苦的事情。