Ten Questions with Sanjiv Shah(OpenMP)以及 Blah Blah
ThinkingParallel 发布了 Interviewing the Parallel Programming Idols 系列的第三部—— Ten Questions with Sanjiv Shah about Parallel Programming and OpenMP 让我对于并行计算的其他解决方案（这次是OpenMP）有了一些了解。
下面是 Blah Blah。
目前的感觉，在并行计算的问题上，存在着N多种不同的方案。各自有着自己的侧重点。
上次参加 BJUG 的聚会，和 dreamhead 也谈到过这个问题。作为硬件厂商 Intel(或者 AMD 也是如此)的思路是通过提供底层的基础库，在编译器优化的层面，不动声色的解决这个问题（这就好像 SSE 指令，搞编译器能帮我们把代码优化到能够充分利用这种能力就行了，大多数程序员都没有知道的必要）。我姑且把这类思路称作“硬件派”——在软件领域几乎不会造成什么影响。
不过由于软件问题的复杂性，对于这种思路的效果，我保留怀疑。
MPI 和 OpenMP 似乎是要试图在我们熟知的“顺序编程”世界，通过革新和改进，扩展出一片并行运算的新天地。它们试图通过在 Pattern/Lib 乃至 Language 层面的扩展，为软件界无比广阔的现有资产（语言/软件/库）引入并行运算的活力，我姑且把它们称作“改革派”——需要学习新的模式和库，也许还需要了解语言的扩展，但大部分的知识还是能够得到继承。
嗯，这肯定会收到一些效果，而且易于被大多数人接受。
Erlang似乎是想通过完全创造出一个新语言（或者说一个 Lamda 的虚拟机）来解决这个问题。把 C/C++/Java 这些主流工业语言的光荣传统，以及数量庞大的丰富资源近乎完全抛弃，通过惊世骇俗的“share nothing”编程思路，力图创造出一个“The World is Parallel”的新世界，那十几年默默无闻的积累也许就是代价。这无疑可以称作是“革命派”——完全不同的编程思路，完全不同的编程语言，一切从新开始。
这让我想到了Ruby——另外一种小众的语言。
这都是解决问题的思路，可，哪一种会得到 Main Stream 的广泛认同？包括 Idols 们在内，恐怕没有人确切的知道这个问题的答案——因为最终的表决权是在 Main Stream 的所有程序那里。不过，在 entering the many-core era 的战役中，至少我们已经有了这几件“武器”可供挑选（或许还会有更多）。anyway 我想引用这段作为我这篇 blah 的结尾：
Three things are necessary: the need mentioned above, coupled with changes in University curricula to teach parallel programming in undergraduate courses and the availability of parallel languages and tools for the entire programming life cycle (from experiment and design to coding to testing and validation to maintenance).
4 and 8 core processors bring the need, University curricula are starting to change, parallel languages are becoming widely available and tools are starting to become available for some of the more common languages.
我这么曲解 Sanjiv Shah 的意思——好戏还在后头。
Comments
我觉得多核的并行运算，各种解决方案，可以体现出各种不同的思路。
一种是通过硬件来解决，程序员不需要做任何改变，使程序员能够专注于应用上的开发。
一种是通过编译器、库来解决。比如Java的Concurrent库，C的OpenMP，MPI这些，程序员只要通过曲线不是太陡的学习，就能够利用已经掌握的工具来创造出新的价值。
一种是破釜沉舟，完全改变思维，使用比如Erlang这样的FP语言。由于不是主流，从某种意义上是“不成熟”，对于很多商业应用来说维护成本极高。我没期望过Erlang能够像Ruby那样靠着ROR红火起来，只希望它能够给有需要的人带来真正的价值。
Arbow 的分析非常理性。
软件工业大量的“资产”依赖于“顺序编程”所构建的软件体系。完全把他们抛弃，显然是非理性的想法。或许大量的软件，只能通过“缓慢的沿革”，过渡到“多核Enable”的状态。这也许才是“工业主流”。
不过对 erlang 来说，走 ruby 的路径也许并非没有可能。其实 ruby 也是一种相对来说也有门槛的 fp 语言，而 ror 之所以火，主要是因为“对迅速 web 开发强烈需求的火”。维护成本或类似的劣势，对 ror 或者 erlang 都是一样的。
Mickaël Rémond 之前也写过一篇 Web 2.0: Shifting from “Get Fast” to “Get Massive” （http://www.process-one.net/en/blogs/article/web_20_shifting_from_get_fast_to_get_massive/ ）或许他所描述的那种“潜在可能”，也是一种有可能的“可能”。
anyway，对于 Erlang 我的期望也不高。更多人知道，那挺好，如果始终都只有一少部分了解，没准正如 potain 所说，还会更好。
其实OPT的很多gen_*（如gen_server、gen_fsm）都是为了将并行编程和错误处理机制与顺序化编程分离开来，使得应用程序的编写只需要进行顺序化编程，以简化应用程序的编写。
@目前匿名 同意，otp 的 gen_* 在我看来，颇有一些类似 design pattern 的意思。
很多高级特性，在 gen_* 的支持代码之中已经替你搞定了，这就好比 service 接口之于 servlet ，如何处理 failure ，如何处理 start/stop，如何处理 hotdeploy。它都已经帮你搞定。你只需要写 application 代码就行了。
“ror 之所以火，主要是因为“对迅速 web 开发强烈需求的火””
确实，如今敏捷Web开发的需求是比较大的，虽然我不从事Web方面的开发，但是从我公司的情况来看，这种“敏捷”对我公司来说是非常必要的。虽然目前ROR的维护成本相对较高，但是随着普及，会越来越好的。
对于Erlang，虽然现在有一个Erlyweb这样的框架，但是我本身不太看好它能取得的前景，这并不是Erlang所擅长的方向，虽然它可能在comet这种需要保持长连接的应用中取得突破。Erlang所擅长的领域，从应用来说都是相对较窄，我希望它在通信，P2P这些领域能先取得突破。
据我了解，有类似呼叫中心之类业务的公司在使用ejabber，但是并没有对Erlang有太大重视，仅仅作为一个能够支撑最多并发连接的jabber server来使用。
To Arbow:
Web应用越来越趋于互动，Erlyweb在这方面是很擅长的，只是现在支持的库不多。将来会不会繁荣起来，很难预料，因为取决于很多因素，技术本身只是一个因素。即使不会成为大众的东西，在技术上能够有很多启发意义，就已经很不错了。
例如当初OO出生于SmallTalk，而发展繁荣于C＋＋/Java一样。
@Sander:
Web的发展越来越趋于互动——我同意你的观点。Arbow也提到了Comet可能会是Erlang的潜在突破方向。今天在 maillist 里面看到 sem 做的 http://www.mycodegarden.org/index.php/Special:Chat (目前还不支持FF)，感觉很好。
我们喜欢一个东西，很自然的也会希望其他的人也来喜欢。这很正常。不过，主流工业是否会接受它，其实是件很没谱的事情。anyway（套用电影“1900”里面的台词，fuck the mainstream）管它主流工业接受与否。也不妨碍我们享受学习与运用这项技术的快乐。
不知道erlang在超级计算方面会不会有用武之地，现有的并行计算差强人意
@我是谁
对“超级计算”这样的课题不了解。
Write a Comment