并行计算：近来语言发展的趋势和我…

    早上收到CSDN的邮件，内容与英特尔的Cilk技术有关。“Cilk 技术让C/C++
程序员更容易地编写多线程程序，继而充分利用多核处理器的计算能力，它已被集成到英特尔 Parallel Composer
2011（Beta）中。”

   
可以说近年来并行计算（在本文中就是多线程程序，但不如并行计算来得装13，所以大家常不爱用）一直是计算机界的热点。有的解决方案是诉诸于另一门语言如
erlang，Go；有的解决方案则是扩展现有语言，如Cilk扩展了c++语法；最温柔的解决方案则是扩展现有类库了，如java的
concurrent库。

   
并发计算成为热点的直接原因就是处理器多核化。主频提高，内存增加，对于程序员来说像是免费的午餐——无需事实上也无法优化代码就能获得性能提升。但是多核处理器不是。如果程序中没有正确高效的并行化措施，并不能从中直接得利。所以C++大师Herb
Sutter在2005年的时候写了一篇文章：“The Free Lunch Is Over: A
Fundamental Turn Toward Concurrency in
Software”，预言在面向对象之后软件开发将迎来并行计算的时代。

   
并行计算、多线程程序不是什么新东西。但是传统多线程开发技术过于依赖编程人员的聪明才智、技巧和经验。即使是java，也只是统一了不同平台的线程函数，语言级别提供同步原语（临界区和条件变量），提供了一些并发基础设施（主要在java.util.concurrent）。并没有从本质上降低并发开发的难度，开发正确高效的并发应用仍然很困难。既然老路子走得艰难，自然得找新路子。下面我分析一下百花齐放的新路子后面的思路，我觉得最重要的是以下两条：

   
1）只读模型。并发程序的一个本质困难是数据的并发访问和数据的修改之间的矛盾。那最简单的解决之道就是不修改呗。如果某个线程一定要修改？先复制一份呗。估计很多程序员看到这里会跳起来：效率呢！呃。其实这点并没有这么难接受。盗版erlang之父的说法：我对并发编程有了自己的感想，之后写了这篇
blog，于是其他人看到了，大家是通过我的blog了解我的想法而不是从我的大脑0xXXXXXX位置拷贝x字节的数据。我们最常遇到的并发——人与人之间的协作千百年来一直都是基于该模型，所以并没有什么好奇怪的。顺便说一句：星际争霸里的神族不是。

    只读模型具体应用：

   
函数式编程典型如erlang，没有变量，当然没法修改（如果够疯狂java、c++一样可以运用函数式编程）

    Go的口号: Do not communicate by
sharing memory; instead, share memory by communicating.

    MapReduce，哪天我再分析一下MapReduce吧，其实说白了也颇容易

    要并发，不要锁，这就是只读模型。

   
2）轻量级线程。又是百花齐放的名词：erlang里面称为process；Go里称为Goroutine；Cilk里称为subroutine；有些地方称之为strand。为啥需要轻量级线程？因为传统线程代价太大了。比如一个1kw元素的数组要在4核主机上进行求和计算。新建4个线程，分别统计不同区间，最后加起来。这样速度会比直接加快吗？不知道，因为创建销毁线程和线程调度的代价不容忽视。正是由于这个限制，传统并发编程时要小心翼翼，生怕多建了线程；中小粒度的工作也无法很简单地用并行技术进行优化（典型做法线程池+消息队列，不能像轻量级线程一样想spawn就spawn）。

   

   
未来的趋势？我想如果并行应用风靡全球，那么erlang和Go的前途是光明的。虽然目前其运行效率还比不上高效的java/c++实现，但：1）两者难度差别很大，高效的c++实现对编程人员要求很高；2）针对并行运用其开发效率有明显优势；3）未来虚拟机可以再优化。想想java是怎样超越c++的，就明白些许的性能优势真的不关键（甚至几倍的性能优势也未必顶用）。至于说到类库的丰富和群众基础，这些都是可以变化的。

   
ps：理论上c++应该比java运行效率高一些，但是我所见的大部分c++程序员，如果换java写程序，估计运行效率会上一个台阶。就像最高档的衣服是手工制作，但是大部分人如果去手工制作衣服，恐怕根本不能穿。c++性能陷阱比java多，对程序员的要求比java高。

   
再ps：我一直认为并发(concurrent)和并行(paraxxxx)是一回事，所以文中混用这两个名词。清晰地定义和区别两个名词，是可以做到的，但我觉得意义不大。

   

 ==============================后记============================================

   
看了erlang的快速排序后，有@@##的感觉，erlang的语法和我的惯常思维方式有点抵触，实在是撑不住。

   
Go居然没有模板（这个还好，java一开始也没有）和异常，没有异常和程序健壮性是抵触的。是的，很多很健壮的程序并未使用异常机制，但我相信如果它们有使用异常机制，收敛到稳定的过程会更快。