GHC 6.6宣布支持SMP

Haskell工业级编译器GHC 6.6版本刚刚发布，重要更新是可以在编译期选择让Haskell线程调度器使用多少本地线程。


Perl6实现Pugs马上采用了这一新特性，并取得明显的提速。

但是，Pugs领导者唐凤(Audrey Tang)又补充道因为受仍然是单线程的GC的限制，提速未能接近理想化的线性增加。并行GC是GHC下一版本6.8的工作目标。

评论

1 楼 cookoo 2006-10-24  

Ocaml.cn的站长code17详细解释了Ocaml为什么不支持SMP的这个令人困扰的问题。

引用

在OCaml社区，对SMP的支持是一个老问题了，据Xavier说，因为每年都有人提这个问题，他每年都需要就这个问题在mailing list上重新布一次道，最近几年当然更加频繁一些。

大概说来，Caml team对SMP的结论从始至终都是这样的：
基于SMP的编程所用的是shared memory parallelism模型，在OCaml里就是thread。在一个有side effect的语言里使用thread programming，既不安全(deadlock/race condition/...)也很复杂(lock/condition/semaphore/...)，这是一般性的常识，并非是OCaml特有。如果是为了并发，用message passing来进行并发编程才是更值得鼓励的模式。
那么OCaml为什么还要有thread？ thread并不仅仅是用来并发加速程序，它有三种应用场景(略...)。比如OCaml最初引入thread library的目的并不是为了并行计算，而是为了提供阻塞式IO与运算重叠进行的编程模式。
那么不支持SMP？(支持它会有什么损失呢？) 这里主要的问题是runtime system特别是GC和存储管理必须是MP-safe的。这在实现上意味着尽量减少global state，并对共享资源的获取设置lock —— 设想如果是简单地对于每次heap allocation都这样做的话，代价显然小不了，如果想减小代价，那么就只能使用复杂的设计，整个VM都会更加复杂化。这些还都是些容易解决的小问题，关键在于GC：如果GC工作在一种“时间停止”的简单模式下——即GC的时候暂停所有线程，那么程序的效率显然会受到很大的限制，而解决这一问题的办法就就是使用真正的concurrent GC。这很难，但对于OCaml来说，这不仅完全做得到而且已经做过了，现在的Caml GC作者在90年代初就做出来过！但后来这个方向被放弃。为什么？ 实现太复杂，太难debug(尽管连机器证明都有)，可维护性存疑，此外还不要忘了这一切问题的解决都是有效率作为代价的(对于那些使用单个CPU的机器——目前的大部分机器，即使不使用SMP，还是一样要为VM里的SMP设计付出额外的代价，除非维护两个非常不同的VM；对于那些没有使用并行编程技术的源代码——目前的大部分代码，即使运行在SMP上，也一样没有speedup只有额外的cost)。
最后的结论是什么呢？ 就是在无法确定在大部分场合下肯定会产生足够的speedup以前，OCaml不会添加对SMP的支持。一个例子是：如果目前常见PC里最新的Dual Core CPU，在理想状况下可以给你170%的speedup(因为一般程序本身就不可能是完全并行的)，而VM添加SMP支持所导致的效率损失是30%的话，那么最后的speedup也不过是170% * 0.7 = 119%，这还是基于你的程序是用并行指令写的以及你的机器是并行CPU的情况，其他情况下的用户只会是损失30%的效率。当然，如果将来常见单机CPU数目增加并且你的程序又可以轻松增加并行度话，情况也许会好一些，即便如此，VM/GC所提供的speedup是否能够在多大程度上scale依然是一个问题。

但是message passing在mutable data难免矛盾巴，除非在语言级别禁止在process里用mutable数据以避免锁。