最近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（事务性内存）就是其中的典范。但是现在它们还只处于研究阶段，里面有一大堆的问题尚待解决，最主要的就是性能还不足以到商用阶段。

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

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

建议继续学习：

1. 多核与异步并行    (阅读：3730)
2. 多核环境下编写程序需注意Cache    (阅读：2046)
3. 多核编程的难题（二）    (阅读：1928)
4. 多核与移动设备    (阅读：1885)
5. 多核的未来    (阅读：1522)
6. 云计算时代的多核开发    (阅读：1489)