並行謬論

發表於2011-06-15

幾乎已經有10年了,科技界的專家們一直談論著摩耳定律的終結。就在本週,《經濟學家(Economist)》發表了一篇文章,講述程式設計師們如何開始使用函數語言程式設計語言來駕馭如今已成為標配的多核處理器。事實上,這些新式語言的發明人,例如Rich Hickey(Clojure語言)和 Martin Odersky(Scala語言),都在勤奮的宣揚這些語言如何給了開發人員們更大的能力來處理複雜的並行性程式設計,來充分利用多核CPU。本週早些時候,我參加了Scala語言日大會,去聽Martin Odersky的講道,他幾乎用了一半的時間來講這個主題。種種資訊一遍又一遍的在向程式設計師表明:你需要寫並行程式,而你不知道如何去做。這是真的嗎,還是隻是一種政治宣傳?

沒錯,我們現在買的計算機都是多核的。計算機時鐘的速度不可能再增長了。我寫這篇部落格用的是一臺2.13GHz、雙核處理器的MacBook Air電腦。五年前我有一臺筆記本,處理器是2.4GHz的。我不是來爭論多核處理器已經成為標配的問題的,我對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這樣的小語言高不到哪去。我想他是對的,但不僅僅是因為函數語言程式設計語言的學習曲線過陡峭。如果這些語言所能提供的只是解決並行問題,那麼,這不能夠成為重視這些語言的理由。

原文:fupeg
  譯文:外刊IT評論

 

相關文章