【轉載】Free Lunch is Over(免費午飯已經結束了)

原文：Free Lunch is Over(免費午飯已經結束了)

 

微軟C++大師Herb Sutter的文章《The Free Lunch Is Over》翻譯，之前本身也常常翻譯，可是都不會上傳博客。我的很喜歡這篇文章，因此以此做爲翻譯生涯的開始。

 

免費的午飯結束了

軟件並行計算的基本轉折點

 

繼OO以後軟件發展的又一重大變革——並行計算

 

你的免費午飯即將即將結束。咱們能作什麼？咱們又將作什麼？

主要的處理器設計生產商，從Intel和AMD到SPARC和PowerPC，已經幾乎窮盡了全部的傳統方法來提升CPU性能。

他們專一於多線程和多核結構而再也不是提升時鐘頻率以及單指令流性能。這兩個特性都已經應用於當今的芯片當中，

特別是，多核已經應用於當今的PowerPC和SPARC4代處理器中，2005年Intel和AMD也將引入這一技術。

事實上，2004年IN-Stat/MDR秋季處理器論壇的主題就是多核，而且許多公司都展現了新型的現代化的多核處理器。

回首往事，從稱2004年爲多核之年至今也沒有很長時間。

 

多核使咱們在軟件開發中至少在接下來幾年內，在面向通用桌面電腦以及低端服務器應用方面帶來重要的轉折點（這剛好是當今軟件銷售的價值體現方面）。

在這篇文章裏，我將詳細描述硬件的變化、爲何硬件會忽然影響軟件發展以及並行計算如何影響你和你將來編寫程序的方式。

咱們能夠確信，免費的午飯已經完全結束一年或者兩年了，只是咱們纔剛剛認識到罷了。

 

免費的性能午飯

 

有一我的盡皆知的現象"Intel生產的，Gates都拿走了"。不管處理器運行的多麼快，軟件均可以找到一種方式耗盡額外的速率。

將CPU提升十倍的速率，軟件一般會找到十倍的工做量運行（或者在某些狀況寫自由工做在十分之一的效率下）。

大多數應用在幾十年內均可以得到免費規律的性能提高，甚至不須要發行新版本或作其餘任何特殊的事情，由於CPU製造商（主要）和硬盤製造商（次要）擁有可靠的更新更快的主流系統。時鐘頻率不是衡量的惟一標準，甚至不是好性能的必要標準，但倒是有指導意義的標準：

咱們已經習慣看到500MHz的CPU被1GHz的替代，1GHz的被2GHz替代等等。今天主流電腦的主頻能夠達到3GHz的範圍。

 

關鍵問題是：增加何時會結束？畢竟，雖然摩爾定律預言會發生指數級增加。可是當咱們到達硬件的極限時，顯然指數級增加不能永遠持續下去。

沒有比光更快的事物，增加事實上必定會緩慢下來甚至中止。（注意：摩爾定律主要適用於晶體管集成度，可是在諸如時鐘頻率等其它領域指數級增加也會發生。

在其餘方面甚至增加更快，最引人注意的是數據存儲的爆炸性增加，但這一重要趨勢適用於不一樣文章。）

 

若是你是一個軟件開發人員，你可能已經搭上了免費桌面電腦性能的列車。對於某些本地操做你的應用是否已經到達邊界？

別擔憂，傳統的智慧離去，明天的處理器將擁有更大的吞吐量。不管如何今天的應用已經日益被諸如CPU吞吐量、存儲速率等其餘因素所抑制（他們常常與IO綁定，

與網絡綁定，與數據庫綁定）對嗎？

 

在過去這些必定正確，可是在可預見的未來這一論斷將會發生錯誤。

 

好消息是處理器將會繼續變得強大。壞消息是，至少在短時間內，增加的主要方向將再也不是迎合當今多數應用的免費習慣之旅。

 

在過去三十年間，CPU設計師已經在三個主要方面得到了卓越成就，前兩個關注與直線流指令執行：

1.時鐘頻率；

2.執行優化；

3.緩存。

 

增加的時鐘頻率意味着須要更多的時鐘週期。提升CPU運行速率或多或少意味着作一樣工做量會更快。

 

優化執行流程意味着每一個時鐘週期作更多事情。今天的CPU運行一些功能更爲強大的指令，它們優化的範圍能夠從外到內，

包括流水、分支預測、同一週期執行多條指令、甚至是從新排序指令執行流程。這些技術都是爲了指令流更好或更快地執行，

而且經過減少延遲以及最大化單位時鐘工做量來擠壓每一個時鐘週期作更多的事情。

 

芯片設計者承受愈來愈大的壓力爲了加速CPU運行速度，他們講冒着改變甚至破壞程序意義的風險使它跑的更快。

 

除了簡單的指令排序以及內存模型：請注意，我剛纔所說的一些"優化"實際上以及不只僅是優化了，由於它們能夠改變程序的意義

以及引發顯而易見的影響，這些已經超出程序員的意料以外。但這卻更有意義。CPU設計師通常都是健全和善的人們，他們一般不會想要傷害一隻蒼蠅甚至你的代碼。

可是近幾年，他們更願意爲了提升每週期運行速率將優化進行到極致，甚至明知這些侵略性的優化會影響到代碼的原始語義。這是海德先生出現了嗎？根本不是。

這種意願只是簡單地表示芯片設計師在提升CPU性能時所面對的極大壓力。他們面對如此重的壓力以致於他們爲了提升運行速率願意承擔改變代碼願意甚至破壞代碼功能

的風險。在讀寫代碼從新排序方面，有兩個格外值得注意的例子：容許處理器對寫操做進行從新排序後果如此不堪設想以致於這個功能必須被關閉由於當對程序進行任意

的寫操做排序後很難了解程序的真正含義。對讀操做的從新排序也會帶來驚人的明顯影響。可是通常它會頗有效由於它對程序員而言不難麼苦難。而且對於高性能的操做

系統和操做環境的需求爲程序員帶來極大的負擔，由於放棄優化的機會被視爲更加愚蠢。最終，設計師將cache與RAM分離並增長它的容量。

主存依舊比CPU慢，所以將須要將它放在離CPU更近的地方，可是卻沒法比片上緩存更加接近。今天，片上緩存的大小已經飆升，主要的芯片上以2MB或更多的二級緩存芯片

爲主。（在這三種史上提升芯片性能的方法中，增長緩存將是惟一將在短時間內仍舊持續有效的方法。稍後我會淺析緩存的重要性。）

 

好了，如上所述，這意味着什麼？

 

首先要認可一件重要的事情就是這一系列事情都與並行計算無關。在這些方面進行加速將直接致使順序程序（非並行、單線程、單處理器）以及併發程序的加速。

這很重要，由於當今的不少主要程序都是單線程的，這也便於我深入的開展話題。

 

固然，編譯器也不得不跟上發展水平。有時，爲了使用新指令（如MMX、SSE）維護CPU的最優效能你須要從新編譯應用。

可是，一般老的應用甚至在沒有利用處理器新指令和新特性的前提先，不須要從新編譯也能夠運行得更快。

 

世界本事一個好地方，可是不幸的是，它卻消失了。

 

障礙，今天爲何沒法生產10GHz的芯片？

 

                                   圖 1 Intel處理器介紹(來自維基百科Intel)

 

CPU性能的增加早在兩年前就已經遇到瓶頸。多數人卻在最近纔開始注意到。你能夠用其餘架構的芯片做爲對比，這裏我僅僅以Intel爲例。圖一表示歷史上Intel處理器的主頻以及晶體管集成度的參數。晶體管的集成度至少如今仍然在增加。可是主頻則不一樣。

 

從2003年開始，你會注意到一個由當前趨勢向更快速率發展的拐點。我增長了一條基準線顯示最大時鐘頻率的極限趨勢。再也不是持續的增加走向，取而代之的是忽然的平緩趨勢。提升CPU主頻變得愈來愈困難，由於這不只僅是一個而是幾個物理問題形成，特別是熱、功耗過大、當前的電流泄露問題。

 

要點：你的工做站的CPU主頻是多少？工做在10GHz嗎？對於Intel的芯片，很長時間以前咱們就能夠達到2GHz（2001年8月），根據2003年的趨勢，在2005年初咱們就應該研發出10GHz的芯片。其實，咱們根本沒有作到。咱們甚至懷疑是否會看到10GHz芯片的出現。

 

嗯，那麼4GHz呢？咱們已經實現3.4GHz了，4GHz還會遠嗎？唉，事實上4GHz彷佛也很遙遠。2004年中葉，你可能也知道，Intel首次推遲它的4GHz芯片直到2005年，在2004年秋天，官方正式徹底放棄4GHz芯片計劃。在撰寫本文之際，Intel計劃在2005年初能夠稍微提升主頻到3.75GHz，但至少對於如今來說，幾乎很難實現；Intel和和大多數處理器廠商的將來在於多核這一相同方向。

 

終有一天咱們會在主流的臺式機上採用4GHz的芯片，但這一天必定在2005年以後。固然，Intel也擁有在實驗室能夠更高速運行的樣品，但卻須要更多的配件，諸如大量的冷卻設備。在未來的某一天你的辦公室也不會配備那樣的設備，或者當你在飛機上使用電腦時沒法放置在你的腿上。

 

摩爾定律和下一代

世界上沒有免費的午飯。——R. A. Heinlein

 

這是否意味着摩爾定律結束了？有趣的是，答案每每是否認的。固然，像指數級增加，摩爾定律終有一天會結束，但這彷佛要等到若干年以後。儘管芯片設計師在時鐘週期方面已經遇到瓶頸，可是晶體管的數量仍舊日益膨脹，CPU也貌似繼續遵循摩爾定律在將來幾年日益增長吞吐量。

 

關鍵的區別，這也是本文的核心，在於性能的提高在至少下一代代電腦中將以不一樣的方式實現。而且當前最新的應用也不會再由於沒有大規模的從新設計和受益。

在不久的未來，也就是接下來的幾年內，新型芯片性能的提高將主要依靠三種主要的方式，只有其中的一種是過去的方式。短時間內性能的提高將由下列因素所驅動：

超線程

多核

緩存

超線程是關於在單一處理器中並行地運行兩個或更多個線程。超線程在今天已經被應用，同時容許多條指令並行執行。一個限制因素是，超線程須要更多的硬件開銷，包括額外的寄存器。它仍然只有一級緩存、一個整數運算單元、一個浮點運算單元等單處理器的特性。超線程有時在合理編寫超線程應用時被稱爲能夠提升5%到15%的性能，甚至在理想條件下能夠達到40%的性能提升。這已經很好了，但仍然沒有提升一倍性能，而且對於單線程應用沒有任何用處。

 

神話與現實：2*3GHz < 6GHz

 

一個由雙核組成的CPU實際上提供了6GHz的處理能力，是嗎？

顯然不是。甚至在兩個處理器上同時運行兩個線程也不見得能夠得到兩倍的性能。類似的，大多數多線程的應用不會比雙核處理器的兩倍快。他們應該比單核處理器運行的快，可是性能畢竟不是線性增加。

 

爲何沒法作到呢？首先，爲了保證緩存一致性以及其餘握手協議須要運行時間開銷。在今天，雙核或者四核機器在多線程應用方面，其性能不見得的是單核機器的兩倍或者四倍。這一問題一直伴隨CPU發展至今。

 

其次，除非雙核運行不一樣的進程，或者同一進程的不一樣線程能夠獨立運行，而且歷來不須要等待其餘進程或線程，他們纔可能被高效利用。儘管如此，我仍舊能夠推測今天運行在雙核芯片上的單核應用也能夠看到顯著的效率提升，不是由於額外的核心實際在作有價值的工做，而是那些能夠減慢單核機器運行速度的廣告插件和間諜軟件。你以爲將其中一個處理器留給間諜軟件是解決問題的方案嗎？

 

若是你正在運行一個單線程的應用，那麼該應用將僅僅使用一個核心。應該有必定的加速比由於操做系統和應用能夠運行在不一樣的核心。可是操做系統每每不會耗盡一個核心的利用率而致使其中一個核心每每空閒。（一樣的，間諜軟件業能夠佔據操做系統的大部分空閒時間。）

 

多核其實是指在同一個芯片搭建兩個或者更多個核心。一些芯片，包括SPARC和PowerPC，已經擁有成功的多核版本。2005年Intel和AMD的早期產品，功能類似只是集成度略有不一樣。AMD彷佛有一些初步性能設計的優點，好比在同一芯片上具備更好的集成度。而Intel的初始方案几乎是將兩個Xeon處理器放置於同一個芯片上。性能的提高應該如同有兩個真是的雙CPU系統通常（僅僅是系統將更便宜由於母版有兩個插槽），這也意味着速度的提高將小於一倍，就像今天這將促進寫多線程應用同樣，而再也不是單線程應用。

 

最後，片上緩存的大小預計至少在短時間內將繼續增加。在這三點中，只有這一點將使大多數的現今應用受益。持續增加的片上緩存的大小將對應用程序很是重要且有益處，僅僅是由於空間即速度。內存訪問的開銷太大，若是有可能你願意儘可能避免訪問RAM。在當今的系統，高速緩存未命中而去訪問內存的開銷通常是訪問緩存開銷的10倍到50倍。這一點，讓人們很驚訝，由於內存訪問與外存和網絡訪問相比要快不少，可是卻不能與訪問速度最快的緩存相提並論。若是某個應用能夠利用緩存的這一特性，那麼咱們就真正利用了多核，不然咱們則沒有。這就是爲何在近幾年內經過增長緩存大小而不須要大規模從新設計也能夠提升不少應用的運行效率。隨着愈來愈多的應用程序處理大量的數據，併爲它們增長若干代碼以適應新的特性，性能至上的操做須要適應緩存的這一特性。就好像大蕭條時期的員工在提醒你，「緩存纔是王道」。

 

(旁白：這是一件最近發生在個人編譯器團隊身上的事情，偏偏證實了「空間即速度」。編譯器使用相同的資源爲32位和64位進行編譯，程序僅僅是被選擇編譯成32位仍是64位。運行在64位機器上的64位編譯器得到了大量的基準性能，原則上是由於64位處理器擁有更多的64位寄存器協同工做以及其餘編程特性。一切都很好，可是數據大小呢？升級到64位並無改變存儲器中的大部分數據，只是一部分指針大小變爲原來的兩倍。當這件事情發生的時候，相對於其餘的應用來講，咱們的編譯器使用了更加繁瑣的內部數據結構。由於指針如今是8個字節而再也不是4個字節大小，這顯然增長了數據大小，在64位工做機制下，咱們的編譯器在數據大小方面增長顯著。更大的工做集幾乎抵消了由更快的處理器與更多寄存器協同工做帶來的性能提升。在撰寫此文之際，64位編譯器與32位編譯器性能幾乎相同。儘管對二者而言資源相同，64位編譯器仍舊提供了更大吞吐量。空間即速度。)

 

可是緩存就是這樣。超線程和多核的處理器對當今大部分應用程序則沒有影響。

 

那麼，硬件中的這些改變又怎樣改變咱們編寫軟件的方式。目前爲止你可能已經看到了一些基本的答案，讓咱們深刻研究它以及它帶來的影響。

 

對於軟件的意義：下一場革命

 

在20世紀90年代，咱們就學會了面向對象的思想。在過去20年裏，也能夠說在過去30年間，在編程領域從主流的結構化編程到面向對象發生了巨大的變革。或許還有其餘的改變，好比最近興起的web編程，可是咱們大多數在一輩子中都很難看到對軟件革命如此重要和深遠的改變。

 

直到如今。

 

從今天開始，性能將不會再白白提高。固然，仍舊存在任何人均可以使用的性能提高的途徑，這主要歸功於高速緩存大小的提高。可是若是你想要你的應用程序重新型處理器的指數級增加的吞吐量中得到提高，就須要精心編寫並行一般是多線程的應用。提及來容易作起來難，由於並非全部的程序在本質上說都是並行的而且並行計算很苦難。我時常能夠聽到一些抗議的報道：「並行計算，這並不算是新聞，人們已經開始編寫並行計算的應用。」一小部分開發者確實如此。

 

請記住在20世紀60年代中後期，人們使用Simula語言進行面向對象編程，可是直到20世紀90年代面向對象纔在主流編程語言中引起一場革新。爲何？革新的主要緣由是咱們的產業被編寫愈來愈大的系統、解決愈來愈多的問題、利用CPU以及存儲資源所驅動。面向對象的抽象及獨立性使得大型軟件的發展更有收益、更可靠及可重用。

 

一樣的，自從黑暗時代咱們就開始進行並行編程，編寫例程、檢測系統以及相似爵士樂的東西。在過去的十年間，咱們已經目擊了愈來愈多的程序員編寫多線程、多進程的並行系統。可是這場變革伴隨着一個重要的轉折點——並行計算的實現變得緩慢。今天絕大多數的應用都是基於單線程的，在下一節我將敘述一些好理由。

 

順便說一下，關於炒做的問題：對於他們的新技術人們老是很快宣佈這是將來軟件發展的革命。不要相信它，新技術每每真正有趣有時有益處，可是這些年中咱們從編寫軟件中得到的巨大革新已經經歷了逐步增加過渡到爆炸性增加的階段。這些是必要的的：你僅僅只能在一個很成熟的技術定義軟件發展的變革，包括穩定的供應商和工具支持，至少在七年前沒有穩定的性能和致命性缺陷前一般採用各類新的軟件技術。做爲這樣一個結果，真正的如面向對象的軟件革新在多年前就已經具備一些優化技術，每每是在十多年前。即便在好萊塢，最真實的「一晚上成名」在得到大突破前也須要由不少年的表演經驗。

並行計算是編寫程序的下一個重大變革。不一樣專家仍舊對它的影響是否比面向對象更大持有不一樣見解，固然這樣的話題最好仍是留給專家。對於技術人員而言，並行計算與面向對象在複雜度和學習曲線上處於同等地位。

 

並行計算的益處和成本

 

並行計算，特別是多線程已經在主流軟件中被應用有兩個重要緣由。首先上，邏輯上具備獨立的控制流；例如，我設計的一個數據庫複製服務程序中，很天然的將每個複製會話放在本身的線程內實現，由於每一個會話徹底獨立不須要其它會話也能夠被激活（只要他們不工做在同一數據庫區域）。另外一個頗不常見的緣由是編寫並行程序能夠提升性能，要麼利用多個處理器的性能或者容易減小程序其餘部分的延遲。在個人數據庫複製服務程序中，該因素也體現的淋漓盡致，分卡的線程充分利用了多個處理器的性能由於咱們的服務器可與其它服務器一塊兒並行計算更多的應用程序。

 

然而，並行計算的開銷卻很大。某些明顯的成本相對不那麼重要。好比，鎖的開銷很大，可是若是你能找到一種合理地方式並行化操做而且減小或消除共享狀態，那麼當你使用正確明智時，你會得到不少性能的提高。

 

可能第二大的成本是並非全部的應用程序都適合並行化。這點稍後我會進行討論

 

最大的成本多是並行化的使用難度：程序模型，即程序員頭腦中的模型，與順序的控制流相比，程序員須要對使用並行化編程有着合理的理由。

 

每個認爲本身理解並行計算的人們，最終將發現本身並無真正理解並行計算。隨着程序員學會對能否並行提出疑問，他們發現這些答案一般在內部測試中被發現，他們從而達到了一個新的理解程度。那麼一般不會在測試中發現的每每是:理解爲何和怎樣作壓力測試？這些是否只是停留在多處理系統表面的並行問題？在單處理器系統上線程將在哪些地方進行切換？他們是否真的同步執行而不產生任何錯誤？這是人們認爲他們瞭解編寫並行程序的心裏疑惑階段：我曾遇到過不少團隊在壓力和擴展測試下應用效果不錯，在許多我的網站運行的也很良好，可是直到真的應用到擁有多處理器的環境下，程序出現間歇性的崩潰。

 

在當今處理器發展前景下，爲了在多核機器上運行多線程程序而從新設計編寫應用有點兒像經過直接跳入最深的泳池學習游泳，真正的並行環境更容易暴露程序設計中的錯誤。即便你擁有一個可以可靠編寫並行程序的團隊，也還會有其餘缺陷；好比，並行程序是徹底正確的可是沒有單核機器運行的迅速，特別是在線程並不能足夠獨立而且共享程序執行所需的單一資源時。此時，狀況變得很微妙。

 

今天絕大多數程序員都沒有真正領會並行計算的真諦，就像15年前大多數程序員尚未領略面向對象的真諦同樣。

 

與從結構化編程到面向對象編程是個飛躍同樣（什麼是對象？什麼是虛擬的功能？我應該如何使用繼承？除了「什麼」以及「如何」外，爲何正確的設計實踐是正確的？），從順序編程到並行編程一樣也是一個飛躍（什麼是空轉？什麼是死鎖？它是如何產生，又該如何避免？什麼樣的結構致使我認爲是並行化的程序其實是串行化。除了「什麼」以及「如何」外，爲何正確的設計實踐是正確的？）。

 

今天絕大多數程序員都沒有真正領會並行計算的真諦，就像15年前大多數程序員尚未領略面向對象的真諦同樣。可是並行化編程是能夠學習的，特別是咱們堅持以消息和鎖爲基礎進行編程，而且一旦領略它，其實它並不比面向對象困難並且使用起來很天然。你只須要爲你和你的團隊準備足夠的時間進行訓練。

 

（在上面的並行化編程模型中我故意強調基於消息和鎖，也有一種無鎖編程，至少被Java5和一種流行C++編譯器支持。可是對於程序員來講無鎖編程要比基於鎖的編程可貴多。大部分時間裏，只有系統和庫的編寫者不得不須要了解無鎖編程，儘管幾乎每一個人都須要利用系統函數和庫函數。坦白講，即便是基於鎖的編程也是有風險的。）

 

對咱們意味着什麼

 

好吧，回到「對咱們意味着什麼」這一話題。

1.咱們已經瞭解到了明確的主要後果：若是咱們想要充分利用以及有效提高的CPU吞吐量，更多的應用程序須要而且在接下來幾年會採用並行化編程的方式。例如，Intel正在談論在未來的某一天研發具備100個核心的芯片，單線程的應用至少能夠利用1%的潛在吞吐量。「喔，性能並不那麼重要，計算機在變的愈來愈快」的言論保守懷疑，在不久的未來，這幾乎是錯誤的。

 

更多的應用須要並行化若是想要徹底利用持續指數級增加的CPU吞吐量。效率和性能的提升將會變得更多，而不是更少，這很重要。

 

如今，並非全部的應用（或者更精確的說，應用的重要操做）適用於並行化。事實上，一些問題，好比編譯，是理想的並行化應用。可是其它的並非，一個經典的例子是不能僅僅由於一個婦女須要花費9個月時間產下一個嬰兒，就意味着九個婦女能夠在1個月內產下一個嬰兒。在此以前你也可能碰到過相似的狀況。可是你有主要到這些現象所引起的問題嗎？這些是回答相似問題的答案：你爲何認爲這個嬰兒問題本質上不能並行化？一般人們錯誤的引用這些類似的狀況證實不能並行化的問題，但事實上不必正確。若是目標是產下一個嬰兒，這事實上是一個非並行化問題。若是目標是產下多個嬰兒，這其實是一個並行化問題。瞭解實際的目標能夠是事情變得大不相同。在軟件研發中，當你考慮是否或如何並行化時，你須要謹記這個以目標爲基礎的準則。

 

2.可能較不明顯的影響是應用與CPU的結合變得愈來愈緊密。固然，並非全部的應用都如此，甚至是若是沒有準備充分就沒法與CPU緊密結合，可是貌似咱們已經到達了「應用於I/O結合、與網絡結合、與數據庫結合」增加趨勢的盡頭，由於性能在那些領域的提高依然迅速可是傳統的CPU性能提高技術卻已通過時。考慮下面這一狀況：如今咱們停滯在3GHz的範圍內。所以，對於單線程應用，除非利用增加的高速緩存大小（這是主要的好消息），彷佛再也沒法提高運行速度。其它的獲利彷佛比咱們過去經常見到的少不少，例如芯片設計師找到新的方式保證流水線滿而避免停滯，這一領域收穫頗豐。新的應用特性並無減小，甚至解決大量應用程序數據增加的須要也沒有中止。隨着咱們期待程序能夠作更多的程序，除非他們採用並行化編程他們才能夠完全榨乾CPU的每一點資源。

 

有兩種方法解決並行化帶來的改變。其中之一是如上所述，使用並行化從新設計你的應用程序。另外一種相對簡單，寫更有效的程序浪費更少的資源。這致使了第三種結果：

 

3. 效率和性能的提升將會變得更多，而不是更少，這很重要。那些具有深入優化的語言重獲新生，他們不須要找到競爭變得更有效、更優化的方式。人們將一直期待以性能爲宗旨的語言和系統。

 

4．最後，程序預壓及系統將逐漸被迫解決並行化問題。儘管爲了編寫更有效更正確的並行化程序，不少錯誤在後來的版本才被修正，Java在最初的版本就已經支持並行化。長期以來，C++也被用來編寫具有多線程應用的系統，可是一直沒有支持並行化的標準（ISO C++標準甚至沒有明確的提到線程），而且典型的並行程序須要由具有與平臺無關的特性和庫文件。（這一般是不徹底的，好比，靜態變量必定只能被初始化一次，這須要由編譯器用鎖包括，可是許多編譯器並不產生這樣的鎖。）最終，產生一些並行計算的標準，包括Pthread和OpenMP，一塊兒其餘的明確支持並行化的標準。使用編譯器檢查你的單線程應用程序以判斷如何使它並行化是很是好的思路，可是自動的轉換工具仍舊有一些限制，而且並不受你本身的代碼控制。主流的基於鎖的編程藝術，很微妙也頗有風險。咱們急切須要一個比當今語言更高效的並行化語言模型。一下子我將談及這點。

結論 

若是你此前沒有作過，如今是時候你從新審視你的應用，決定哪些操做時CPU敏感型的以決定在那些地方是否可使用並行計算。如今對於你和你的團隊也是時候領略並行編程的徐需求、誘惑、風格和用法。不多一些應用天生適用於並行化，但大多數並非這樣。甚至當你確切瞭解到哪些是CPU緊密型時，你也會發現將那些操做並行化很是困難。全部開始學習並行計算的緣由是並行計算是軟件開發的下一次變革。並行編譯器能夠起到一些做用，可是不要過度期待。他們永遠沒法與你經過明確的並行化以及多線程使串行程序並行化的程度相提並論。

 

感謝高速緩存大小的增加以及指令控制流的優化，免費的午飯還會延續一段時間；可是如今開始提供的東西將會少不少。吞吐量的增加仍舊持續，可是須要額外的研發精力、額外的代碼複雜性、額外的測試精力。好消息是不少類應用的額外努力是值得的，由於並行化將使得它們繼續利用處理器吞吐量的指數級增加的優點。