【原创翻译】The 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緊密型時,你也會發現將那些操作并行化非常困難。所有開始學習并行計算的原因是并行計算是軟件開發的下一次變革。并行編譯器可以起到一些作用,但是不要過分期待。他們永遠無法與你通過明確的并行化以及多線程使串行程序并行化的程度相提并論。
?
感謝高速緩存大小的增長以及指令控制流的優化,免費的午餐還會延續一段時間;但是現在開始提供的東西將會少很多。吞吐量的增長仍舊持續,但是需要額外的研發精力、額外的代碼復雜性、額外的測試精力。好消息是很多類應用的額外努力是值得的,因為并行化將使得它們繼續利用處理器吞吐量的指數級增長的優勢。
轉載于:https://www.cnblogs.com/bombe1013/p/3294307.html
總結
以上是生活随笔為你收集整理的【原创翻译】The Free Lunch Is Over的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 哪吒闹海故事英语翻译
- 下一篇: 田家四季歌好词好句摘抄