转载

关于并行的一些错误认识

英文原文： The Concurrency Myth

几乎已经有10年了，科技界的专家们一直谈论着摩耳定律的终结。就在本周，《经济学家(Economist)》发表了一篇文章，讲述程序员们如何开始使用函数式编程语言来驾驭如今已成为标配的多核处理器。事实上，这些新式语言的发明人，例如Rich Hickey (Clojure语言) 和 Martin Odersky (Scala语言)，都在勤奋的宣扬这些语言如何给了开发人员们更大的能力来处理复杂的并行性编程，来充分利用多核CPU。本周早些时候，我参加了 Scala语言日大会，去听Martin Odersky的讲道，他几乎用了一半的时间来讲这个主题。种种信息一遍又一遍的在向程序员表明：你需要写并行程序，而你不知道如何去做。这是真的吗，还是只是一种政治宣传？

没错，我们现在买的计算机都是多核的。计算机时钟的速度不可能再增长了。我写这篇博客用的是一台2.13 GHz、双核处理器的MacBook Air电脑。五年前我有一台笔记本，处理器是2.4 GHz的。我不是来争论多核处理器已经成为标配的问题的，我对4GHz的CPU不感兴趣。我要说的问题是，对于开发人员来说，因为多核处理器的出现，学习并行性编程就真的这么紧迫吗？首先让我们来看看有哪些开发人员。我打算在这里只着眼于应用程序开发人员。为什么？我想，大部分的开发人员都属于此类，而他们正是目前的“并行运动”的目标对象。这也能让我自上而下的方式来处理这个问题。

你平时使用的都是些什么类型的软件？既然你在读这篇博格，我猜测你会使用很多种的web软件。事实上，众多的应用程序开发者都可以精确的归类为 web开发者。让我们从这些家伙们说起吧。这些人需要学习并行编程吗？我想这答案应该是“不，真的不需要”。如果你在开发一个web应用程序，你不需要什么并行性编程。你很难能想象出，在一个web应用里，一个HTTP请求过来，会引出一打的线程(或处理器，类似的东西吧)来响应。现在我倒觉得事件驱动编程，就像你在node.js里看到的，会变的越来越常见。这必然的会打破请求和响应线程之间的1：1对应关系，但这绝对不是要求/请求/建议应用程序开发者们去处理任何的并行算法。

多核处理器给web应用程序带来了很多的好处，这是确信无疑的。日常的应用程序服务器能处理越来越多的并发请求。对于web应用程序的能力增速来说，摩尔定律一点都没有打折扣。但这并不需要所有的这些PHP，Java，Python，Ruby web开发者去学习任何的并行性知识。我承认，有些这样的应用程序需要你在后台用线程处理。然而，这也只是在某些情况下，如果一种应用总是需要开发人员使用这种类型的编程，这反而是一种异常情况。也许你的程序的某块代码需要并行性操作，但只是个技巧问题。这跟多核CPU处理没有任何关系。

现代的web应用程序并不只是服务器端的部分。还有很多客户端的程序，我说的是Javascript。而在JavaScript技术里唯一能做到并行编程的只有Web Workers，这是一个目前还没有被所有浏览器实现的技术标准。这看起来没有大多的吸引力。很难说它会成为JS开发的一项关键技术。当然，在JS开发里一项最关键的API就是XMLHttpRequest。它实际上确实牵涉到多线程技术，但这对应用程序开发者来说却是透明的。

现在有人会争论到，在web技术的服务器端和客户端，其实都有大量的并行计算，只是这些计算是被基础平台管理(web服务器和 web浏览器)。这没错，但，同样，这只是在这种情况下有。它跟多核处理器没关系，大多数广泛使用的web服务器和浏览器都是用C++和Java这样的语言写成的。

所以，是否可以很公平的说，在你开发web应用程序时，你基本上可以忽略这些多核CPU的喧闹？你可以不去理会Rich Hickeys 和 Martin Oderskys 倡导的世界吗？你可以一直坚守你的PHP和JavaScript吗？是的，我想可以。

Web应用程序并不是唯一类型的应用程序。还有桌面程序和手机移动程序。这些应用的开发总是和并行性相关。客户端应用程序开发者一直在努力管理多线程问题，来让程序的界面有更好的响应速度。同样，这并不是什么新技术。这也跟多核处理器没有关系。事实上，并不是过去应用程序程序员一直使用单线程处理任何事情、当多核出现时你才有办法去管理多线程。目前，这种程序的开发者们可以利用函数式编程，我想只是很多的选项中的一种选择。我不认为在这桌面应用和移动应用上，Hickeys 和 Oderskys 创造的世界会成为真的那么有用的东西。

那么，如果你是一个桌面或移动应用的开发者，你应该考虑多核CPU和函数式编程的问题吗？我想你多少应该知道一点这方面的知识。特别是当做了很多的优化工作，仍然不能达到满意的性能要求时。这对那些需要考虑你的使用情况的语言/运行时设计者们更是如此。

我说过，我只想谈论针对应用程序开发人员的事，但我是在撒谎。还有另外一种计算方式越来越普遍，那就是分布式计算。或者称作云计算？我不能待在那么高的地方。问题是现在有很多的软件系统都是运行在计算机集群之上的。很显然，这就是并行编程，这下，函数式编程大显威风了吗？未必。分布式计算并不牵涉到函数式编程中能做到的共享可变状态信息。分布式map/reduce系统，比如Hadoop，对可变状态的共享处理的非常的复杂，尽管它是用Java写成的。这并不是说分布式系统不能从Scala这样的语言中获得好处，只是这些好处对于这些语言上所鼓吹的并行问题/函数式编程来说不是必须的。我承认 Erlang/OTP 和 Scala/AkkaI 给分布式编程提供了很多好处，但这些框架是来解决其它问题的，而不是是多核的并行问题。

听起来我就像是一个专横的守旧的程序员，但其实我是非常喜欢Scala语言和Clojure语言的，跟我喜欢其它的函数式编程语言一样(例如 Haskell)。只是我觉得他们的那些吹鼓用于这些语言上并不太合适和正确。我想并行/函数式编程技术在移动计算领域会有一定的功用(桌面领域也是，但前景黯淡)。毕竟，平板电脑已经走向了多核，多核的智能手机也大批的出现。但这些语言中这方面还有很多要改进的地方，因为在智能手机上已经有成熟的框架和标准模式来处理并行问题。web应用的事件驱动开发方法是另外一个有趣的东西，但函数式语言更多的是给框架的创建者提供了更多的方便，而不是应用程序开发者。我的朋友David Pollak最近写了一篇文章说，他对函数式编程语言所报的期望对比像 Eiffel这样的小语言高不到哪去。我想他是对的，但不仅仅是因为函数式编程语言的学习曲线过陡峭。如果这些语言所能提供的只是解决并行问题，那么，这不能够成为重视这些语言的理由。

原文 http://www.techug.com/the-concurrency-myth

正文到此结束