分类： 业界评论

刚刚过去的一个月一直都在忙着赶实验赶论文，直到前几天完成一篇短论文的写作才得以抽身来补上这一篇关于多核的曙光的文章。我将分几个方面来阐述一下我对多核上并行编程持乐观态度的原因。

1. 较易并行化的应用

如果一个应用的子任务之间依赖关系比较小，相互独立性强，那么它就具有很好的可并行性。很容易我们就会想到服务端的应用。服务端应用的特征就是为多用户提供相似的服务，因为它本身具有内在的并行性，所以相比那些子任务之间依赖性很强的应用来说，它们是比较适合多核的。这些应用常见的例子有大型数据库、飞机票预订系统、银行交易系统、网络搜索、游戏服务器以及云计算所提供的软件即服务（SaaS）等等。

另一种大量采用并行化的成功案例就是图像处理了。举个简单的例子，渲染一幅图像这个任务就充满了大量的数据级并行（data-level parallelism）：一幅图像是由许许多多的像素组成的，而现在的GPU都有成百个核心，我们可以比较容易的做到让每个GPU核心分别负责渲染图像的一部分，从而快速的完成整个计算任务。虽然现在来讲GPU上面的编程很难，但是它所能提供的性能提升确实非常可观。

还有很火的GPGPU应用（General-purpost computing on GPU），它们在Scientific Computing领域也有不少成功案例，虽然John Carmack就在Twitter上对GPGPU编程的困难性这样评价过：“Hundreds of GPGPU research papers valiantly struggling with graphic API limitations are painfully obsolete with CUDA / OpenCL available.”其实Scientific Computing可以算是多核上的杀手级应用了，典型的例如天气预测、气候模拟等运用，为了得到更精确的结果肯定就需要处理更多的数据，而且是必须在短时间内出结果，要不然你预测后天的天气但是一个礼拜才给你出结果怎么行？这些大数据量的计算任务对性能的需求永远都是非常大的。而且这些应用本身有很多数据级的并行性，再加上这个领域一般都是行业专家和软件工程师的组合，大规模的应用并行计算是很自然的事情。

2. 我们有持乐观态度的理由

为什么我们可以对多核发展持乐观态度？因为第一点，现在整个工业界、学术界都在研究多核，研究怎样简化并行编程、怎样降低功耗、怎样持续提升性能。Intel和Microsoft资助UIUC和UC Berkeley建立了两个重点实验室，其他顶级研究机构对多核的研究也如火如荼，大量最顶尖的人才都在帮助普及并行计算。第二点，Motivation，即“动机”。免费午餐都结束了，想继续提升性能？你只能进行并行编程。不管是客户端应用也好服务器端应用也好，用户对性能的需求肯定是不会停止的。当并行编程成为持续提升性能的唯一选择时，再困难你也得去做对不对？不过大家不用特别担心，对广大的程序员来讲，一项新技术的普及本身就是需要时间的，现在来讲大量帮助程序员进行并行编程的软硬件工具都在处在发展阶段，我们有理由相信并行编程会更容易更大众。

3. 多核的发展趋势

9月初我去参加斯德哥尔摩举办的Multicore Day时听了一位在Intel负责Nehalem的首席工程师的演讲，里面有几点我记忆深刻：
（1）单核的性能仍在提升
虽然整个工业界主题是往多核发展，但是处理器的单线程性能仍然在持续提升，这是由需求决定的。例如Nehalem架构的i7的单线程性能是奔4的5倍，这一需求也在Google在Micro 2010的论文”Brawny cores still beat wimpy cores, most of the time“中得到印证。这篇文章的核心观点就是性能较弱但是功耗较低的”小号“处理器只有在它们的单核性能接近中档的”大号“处理器时才具有足够的竞争力，否则它们羸弱的单核性能会成为Google现有应用中的性能瓶颈。虽然当初整个业界因为单核性能提升太困难而被迫转向更易实施的多核
（2）CPU和GPU的融合趋势
现在业界已经认同GPU比CPU更适合做数据级并行，而且这类应用需求量很大，这种需求就催生了Intel的Larrabee项目。虽然Larrabee流产了，但是它的技术还在，以后迟早会出现在Intel的产品线上。为了追求更高的性能，GPU和CPU结合的方案会是最好的选择，当然，怎样在这样的硬件上编程又是一个很大的难题。
（3）性能与功耗都重要
Intel的工程师一直在努力确保处理器的性能提升的同时它的功耗也一直在稳步下降。为什么说功耗很重要？我们可以举个很简单的例子，笔记本电脑上运行PowerPoint的速度已经很快了，让PowerPoint运行速度快个一两倍其实并不那么重要，但是如果在保证它运行速度的同时还能让笔记本的续航时间提升一些，这就很有意义了。服务器端更不用说了，现在哪个数据中心不把功耗当做头等大事来考虑？

4. 并行编程的普及教育

虽然说传统的应用一直都以串行计算为背景，所以现在来讲大家普遍觉得并行编程很困难。但是我们换个思路看看：如果从大一开始我们就教新生《并行算法》《并行编程导论》呢？如果程序员一开始就接受的是并行编程的教育，并行编程还是困难的吗？其实我们整个世界本身就充满了并行，人可以同时听课和做笔记，同时吃饭和交流，而计算机硬件更是可以并行工作，为什么软件就不可以？算法导论最新的第三版专门添加了一章《多线程算法》，（该书其中一位作者Prof. Charles Leiserson创办的并行编程的公司Cilk Art也已被Intel收购）让我大胆想象一下，整本算法导论通篇都是“并行”的时代还会远吗？

最近David Patterson老爷子（就是计算机体系结构–量化方法的作者之一）发表了一篇文章《The trouble with multicore》，文章高屋建瓴的分析了一下多核发展的当前形势，文章开篇就说了一句话“造芯片的家伙们正忙着生产那些大多数程序员不知道如何编程的多核CPU”。这不由的让我想起我跟我导师Per Stenstrom的一次对话，我问他说“现在多核出来了，有一大堆新的难题等着我们去解决，作为研究人员您是否觉得很兴奋呢？”结果他说“其实我还是有点沮丧的，因为我们是被迫转到多核上来的。”

其实这就道出了多核发展中的一个关键：造硬件的没办法在单核上继续像以前那样容易地提升性能了（有兴趣的朋友可以查下“Power Wall”），为了利用更多的晶体管提高性能，只好走多核这条路，但是在他们选择走这条路的时候，所有人都不知道该如何在多核平台上有效的进行编程，David Patterson管这个叫“Hail Mary”，简单翻译过来就是“让我们多核吧，但是该咋进行多核编程就祈祷奇迹的发生吧！”

好吧，为什么多核编程很困难？一个形象的例子就是把编程比作写书，理论上10个作者同时写一本书应该会比一个人写快10倍。但是他们首先要把任务均匀的分成10份，否则任务最多的那个作者会拖后腿肯定就快不了10倍了。但是呢光这个还不够，如果这个故事中的某一部分必须要在其他部分写完之后才能写，这种顺序上的依赖关系也会拖慢速度；而且10个作者的故事情节还得一致，那么他们肯定少不了沟通啊，这又慢了一点。这就是三个多核编程的最大挑战：“load balancing（负载均衡）”、“sequential dependency（顺序依赖关系）”和“synchronization（同步）”。

难道就没有人尝试着解决这个问题吗？有啊！从60年代开始，一堆一堆的天才们尝试着创造新的编程语言好让并行编程更加美好：APL，Id，Linda，Occam，SISAL等等，他们中有的确实让并行编程更加容易了，但是没有一个人能成功的让他们向传统的串行编程语言一样兼具性能、效率和灵活性，更没有像C/C++、Java这样主要为串行编程设计的语言一样流行。我记得有人问过“Java的并发包挺好用的啊，是不是足够解决多核编程的问题了呢？”，我觉得不然。在语言上进行并行编程的扩展确实是有效的办法，但是它却不能从根本上解决并行编程困难的问题。最根本的原因是这些语言并不是天生为并发而设计的，这就决定了所有的库都只能给你提供并行编程最原始的工具，但是对程序员来说并行编程却并没有因为有了这些库就变得更容易了，你还是得面临死锁dead lock、数据竞跑data race、伪共享false sharing、锁竞争lock contention等种种问题。

讲到这我就想起Erlang了，它就是一种天生为并发设计的语言。它的并发模型核心是基于消息传递机制的轻量级进程，进程之间不共享内存。这样的模型好处就在于每个进程是相互独立的，要通信就发消息好了，最大程度上减少了进程间的依赖关系，从而能提高整体性能，而且核越多跑的越快。但是我们要考虑到Erlang最初是Ericsson为电信系统设计的语言，由它编写的程序的目标就是为了提高系统的throughput以便为更多的用户提供服务，这也是大部分服务器端程序的目标。它们的共同特征是每个用户的请求大部分情况下都是彼此独立的，所以多核对这样的高并发应用来讲其实是有点天生一对的感觉。但是对于传统的客户端程序来讲，latency才是它们的首要目标。例如大型的商业软件，它所希望的是完成一个任务的速度能够更快，或者单位时间内能处理更多的数据。

另一个解决并行编程难的思路就是设计更易进行并行编程的硬件，现在最火的Transactional Memory（事务性内存）就是其中的典范。但是现在它们还只处于研究阶段，里面有一大堆的问题尚待解决，最主要的就是性能还不足以到商用阶段。

还有的人尝试过用编译器自动并行化，但是多年的研究表明纯粹让编译器来给你进行自动并行化是完全走不通了。它能在一定程度上提升程序的性能，但是非常有限，而且随着核数的增加它对性能的提升会更加有限。

那么多核时代的曙光在哪里呢？请看我下一篇文章。