http://blog.csdn.NET/babyfacer/article/details/6902985

原文鏈接：http://www.hpcwire.com/hpcwire/2011-06-09/top_10_objections_to_gpu_computing_reconsidered.html
作者：Dr. Vincent Natoli, Stone Ridge Technology （http://www.stoneridgetechnology.com/ ）
譯者：陳曉煒（轉載請註明出處 http://blog.csdn.net/babyfacer/article/details/6902985）

譯者註：根據文章內容，將原文標題（Top 10 Objections to GPU Computing Reconsidered）稍作意譯。

近幾年GPU的出現，對高性能計算領域發展可謂是起到了不可估量的推動作用。GPU計算對性能的數量級提高使得它獲得了比傳統解決方案更多的成功案例。

大量科技工作者熱愛、追捧或使用GPU技術，但同時還有更多的人因為各種原因坐視不理。本篇針對後者，總結了一些對GPU計算領域最常見的問題、顧慮或主觀臆斷等。

接下來的內容將嘗試解決這些質疑，通過GPU計算的進展和我們對未來科技發展的預測來重新思考這些問題。當然，GPGPU不是所有HPC應用的終極解決方案，但是很多人也會發現這項技術在性價比上的優勢，以及它能在諸多領域的成功應用，比如地震圖像學、電磁學、分子動力學、金融定價估價模型、醫療圖像領域等等。

1. 我不想重寫我的代碼，或重新學門語言

如果要使用GPU，重寫代碼是肯定的。其實你將目前的串行程序編寫為並行執行的CPU程序也是需要重寫代碼的。關鍵的問題是你的目標平臺到底是什麽。如果目標是多核CPU，那麽它的並行處理建立在對進程（process）、線程（thread）和寄存器（register）級別的三層模型處理上，你需要用到的是MPI、OpenMP/pthreads 和 SSE/AVX 擴展等。其實用CUDA為GPU編程並沒有比上面的處理更困難，優勢還體現在它對計算限制（compute-bound）和內存限制（memory-bound）上都能有顯著的性能提升，我們待會將談到。

如果你已經有了並行的代碼，那你將其用GPU實現有何好處呢？針對代碼的芯片級比較，計算上一般會有5到40倍的提高。這在采用了GPU的方案上能看到很多出版物予以佐證。在過去的幾年，這些陸陸續續的比較結果是基於Intel和NVIDIA的產品。

CUDA是C程序的擴展，對於有經驗的程序員來說很容易上手。現有的並行編程模型想實現百億億次（exascale）運算還不現實，但我相信最終的解決方案相比CPU並行處理方式而言，看上去應該更像CUDA並行模型。我之前說過，CUDA迫使程序員去思考如何將他們不可減少的並行處理問題對應到線程上，這是一個好的並行編程模型，可以讓問題在單節點多GPU和多節點上都能得到較好的擴展性。

在這個方向上學術界已經有一些非常好的成績，比如Global Memory for Accelerators (GMAC) ，商業界也有擴展性非常好的HUESPACE API（由挪威奧斯陸的一家公司HUE提供），還有他們的兄弟公司，專註在石油和天然氣的GPU應用開發，Headwave公司。

2. 我不知道用了GPU計算能達到什麽樣的性能

HPC代碼不是有計算能力限制（compute-bound）就是有內存限制（memory-bound）。對於compute-bound的代碼，我們可以用NVIDIA Fermi M2090和Intel Westmere做個比較。Fermi有512個核，1.3GHz，而Westmere有6個核，3.4GHz。在核心赫茲上的比較，前者是後者的32倍。如果你的CPU代碼可以有效地使用SSE指令的話，也許在CPU這邊可以再提升4倍，那麽前者還是後者的8倍（接近GFLOPS峰值的比例）

對於memory-bound的代碼，GPU的內存帶寬是177GB/秒，CPU為32GB/秒，前者是後者的5.5倍。這裏前提是你的代碼達到compute-bound，GPU性能會5倍於CPU（針對SSE指令高度優化過的代碼），最高有20倍（對於某些特定代碼）。如果你的代碼是memory-bound，GPU大概會有5倍的性能提升（芯片對芯片的比較）。

當商討並行解決方案時，考慮邊際成本是有幫助的。

• 如果代碼是memory-bound，你應該考慮用最便宜的選擇來增加帶寬，要麽是加一張GPU卡，大約是每GB/秒需15美元；要麽添加一個節點，名義成本大約是每GB/秒需80美元，後者方法還增加了計算能力和操作系統的負擔。
• 如果代碼是compute-bound，計算方法類似，可以得到Gigaflops的邊際成本。
• 如果代碼是compute-bound和memory-bound都存在，大多數代碼，GPU在隱藏memory-bound延遲，提高compute-bound 方面表現較好。

3. PCIe帶寬會嚴重影響我的性能

有人針對PCIe帶寬限制來質疑GPU計算效能，這的確是因為計算密集（大計算量）的一個問題。計算密集（Computational intensity）有很多種定義，其中之一是用FLOPS，也就是每秒運算多少次浮點數操作。將每個數據傳輸到GPU板子讓GPU運算，其中存在一個傳輸上的閾值。

比如，PCIe v2.0 x16 帶寬大約是每秒6GB，在M2090板上填充6GB數據大約需要一秒鐘，計算峰值可以達到665GFlops。M2090是個浮點數運算怪獸，每秒可以處理這麽大的數據量。如果在這個例子中，你想讓PCIe數據傳輸時間不超過計算時間的十分之一（也就是數據傳輸不要影響到計算），那麽在數據每次就緒之前，M2090必須做成千上萬次的浮點運算，所以必須盡可能快地去傳輸數據。

此外，CUDA允許PCIe數據傳輸采用異步重疊（asynchronous overlap）方式。靈活使用該方式可以在計算時隱藏部分或者全部的PCIe數據傳輸時間。成功案例有物理學中的Finite Difference Time Domain (FDTD)算法和分子動力學中的N2粒子與粒子交互等，都能顯著做到數據重用和高計算密集度。

某些算法在GPU上並不是太有效，比如簡單的向量積，計算量很小。如果問題需要在多個GPU上協同運算，那麽要盡量減少數據傳輸的時間。

4. 如果解釋Amdahl定律帶來的啟示？

Amdahl定律量化地揭示了一個事實：如果你打算對大段串行代碼的一部分進行加速的話，不管你用什麽方法，除非去加速提升最大的部分，否則不會有太大的提高。簡單地說，一個程序中如果50%的處理都需要串行進行的話，speedup 只能提升2倍（不考慮事實上有多少線程可用）；如果程序的10%需要串行進行，speedup 最多能夠提高近10倍。Amdahl定律同樣量化了串行化的效率開銷。在擁有10個處理器的系統中，程序如果有10%是串行化的，那麽最多可以加速5.3倍（53％的使用率），在擁有100個處理器的系統中，這個數字可以達到9.2（9％的使用率）。這使得無效的CPU利用永遠不可能到達10倍（參見鏈接：http://sesame.iteye.com/blog/428011）。

針對上述論斷，對GPU並行性能提升最有效的反駁就是根據觀察，現代計算機體系架構想要提高性能，必須將所有代碼盡可能的做到大規模並行化，並且盡可能地去減少串行代碼，不論是在CPU平臺還是在GPU平臺上。問題是，你是想在CPU上並行化你的代碼呢，還是在GPU上？

5. 萬一NVIDIA公司倒閉了怎麽辦？

HPC歷史上有許多超級計算公司，致力將並行計算推上一個又一個新的臺階，比如Thinking Machines，Maspar，KSR，Mitrion等公司。它們付出的艱辛努力和公司的幕後功臣的創造性思維讓我們對什麽可行什麽不可行有了深刻的理解。他們非常值得我們感謝和尊敬。

但是NVIDIA，並不是一家研究超級計算的公司。這個盈收近50億美金的公司，大部分收入是來源於顯卡和賣給PC遊戲市場的嵌入式處理器。這種相對獨立性對於HPC而言是優勢，而且如果所有使用GPU的HPC全部消失，NVIDIA公司仍舊可以活得很好。只要有一幫重度遊戲愛好者圍繞在NVIDIA旁邊就行。事實上，NVIDIA公司在市場上比那些HPC常青樹公司更有競爭力，保險系數更高。

而且，NVIDIA公司發布了他的願景和六年的科技發展藍圖，字裏行間可以顯示出他們想將GPU從傳統的圖形加速角色轉移到計算機架構中心位置的的野心（BBF註，也就是想做CPU啦）。順著這條路，他們會計劃發布更加強勁的計算引擎。

（BBF註：其實這裏也可以用OpenCL，畢竟是一個聯盟，而且與CUDA類似，只不過目前還相當不成熟。）

6. GPU板不能針對我的問題提供足夠使用的內存

對於M2090和M2070的GPU板，板上內存有每秒6GB的傳輸限制。這對於需要某些數據量超過內存限制的算法會出現問題，可以在單節點上用幾張卡並行處理來解決問題。（作者用Dell C410 PCIe機器可以裝16張NVIDIA的GPU卡舉例，這裏不細說了）

目前最多的問題是算法需要實質上的對大數組的隨機訪問，比如大哈希表或者其他需要隨機數組查找等。現在的GPU板對於這些問題還未有一個有效的解決方案。但是內存越來越便宜，存儲密度也越來越高，相信將來的GPU板會裝載性價比更好的內存。

7. 我可以等更多核的CPU，或者Knights Corner計劃

多核有助於解決 compute-bound 的應用，但是應該意識到，當更多的核被加到CPU中的同時，同樣的事情也在GPU身上發生。比較一下CPU和GPU發展藍圖，可以看出他們在計算和帶寬上的差距。這種情況還將繼續下去。對於 bandwidth-bound 的問題，情況或許更差，因為加核比加帶寬要顯得更加容易。

Intel計劃出Knights Corner，宣布了一年多，他們也意識到GPU是x86並行數據處理的競爭對手。有關Knights Corner的詳情目前仍不得而知，我們估計有50個核，1.2GHz，每個核有512位向量處理單元，支持4個線程並行，是HPC的強勁對手。但是這個計劃的開發模型、價格、公布日期和其他很多關鍵信息，到目前為止都是未知數。

坊間爭論 Knights Corner 也許會成功，因為於x86架構統治著HPC計算領域。隱居HPC世界的科學家們需要尋找更廣闊的市場來拓展高性能計算，圖形圖像也許是個選擇，在這方面NVIDIA和AMD已經做的很不錯了。

8. 我不喜歡專有的語言（proprietary languages）

專有語言這裏指某種被某一機構所支持的語言。它可能會發展到一個未知的或者不希望去的方向，或者失去機構的技術支持。CUDA可以歸為此類語言。不過使用CUDA的優點也是顯而易見的：1. 它可以利用NVIDIA硬件獨有的某些優化特性；2. 沒有某一個委員會對藍圖發展做簡單決策；3. 它能更快地支持新的NVIDIA硬件特性。

但是，如果專有語言在您的機構無法被采納，也許OpenCL作為一個非專有語言進行開發，是一個絕佳的選擇。OpenCL，被Apple、NVIDIA、AMD、Intel等諸多知名廠商支持，提供跨硬件平臺的易用功能。我這裏強調功能上易用，與此對應的是性能上的代價。相比CUDA內核，OpenCL內核顯得相當簡單，在主機端的設置和啟動代碼也有更多的不同之處。

9. 我在等CPU與GPU代碼轉換器這種魔術工具出現

對於這個，有個好消息，也有個壞消息。好消息是這種CPU到GPU的轉換器已經有了，壞消息是它產生的代碼和專家編寫出來的代碼，性能上無法相比。可以用The Portland Group (PGI) 的 PGI Workstation 和/或 CAPS HMPP workbench去測試一下。

10. 我有N個代碼需要優化但是IT預算有限

說白了，這就是“要麽不做，要麽就徹底做到位”的尷尬。添加支持GPU的節點到有固定預算的機構基礎設施中，需要在兩個選項中做出選擇，要麽是更強大的異構GPU節點，要麽就是不夠強大的傳統CPU節點。對於以後系統升級，從經濟的角度來看，某些機構要麽100%選擇GPU節點，要麽幹脆不選擇。這對於那些全年無休，存在市場競爭的商業機構中的集群更是如此。分析這種IT架構復雜調度系統，最壞的情況下，所有東西都需要CPU和GPU兩個版本：集群管理腳本、調度、編譯器、測試驗證、應用程序代碼等等。

大型商業機構采用技術都需要考慮投資回報率ROI。“要麽不做，要麽做到位”這個爭論，表現出一些有遠見、深思熟慮的機構對於用可量化的已知成本來面對科技轉化所產生的未知成本時所面臨的困境。最後這點和上面九點一樣，在某些方面要麽和投入相關（代碼開發，人員技能，新硬件，再培訓費用），要麽和回報相關（性能，可擴展性，耗費能源）。

每個公司必須有它自己的ROI公式來處理上述問題。使用傳統的財務分析，資本的投資必須要對股東有利，也要和公司其他方面的投資做比較（BBF註：這裏翻譯得比較簡單，其實就是要周全考慮各方面的投入）。

總之，GPU計算在HPC市場上的持續投入，最近四年有了非常顯著的收益。上述的十大質疑來源於個人和機構，他們都想解決上述問題。GPGPU並不是所有HPC問題的解決方案，但是不應該為錯誤的判斷理由而錯失能給性能上帶來顯著提高的技術。

最後，各個機構應該向GPU計算邁出一步，因為這不僅僅是今年的解決方案，而是一個深思熟慮後得到的策略。這個策略不僅解決了當前的成本問題，也是邁向未來架構、編程模型和實現百億億運算的最佳解決方案。

GPU計算的十大質疑—GPU計算再思考