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

作者：陳曉炜

原文連結：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計算邁出一步，因為這不僅僅是今年的解決方案，而是一個深思熟慮後得到的政策。這個政策不僅解決了目前的成本問題，也是邁向未來架構、程式設計模型和實作百億億運算的最佳解決方案。

源自作者個人部落格