關于并行的一些錯誤認識

英文原文： 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這樣的小語言高不到哪去。我想他是對的，但不僅僅是因為函數式編程語言的學習曲線過陡峭。如果這些語言所能提供的只是解決并行問題，那么，這不能夠成為重視這些語言的理由。