GPU并行化編程優(yōu)點(diǎn)及未來(lái)發(fā)展趨勢(shì)

隨著GPU的可編程性不斷增強(qiáng)，GPU的應(yīng)用能力已經(jīng)遠(yuǎn)遠(yuǎn)超出了圖形渲染任務(wù)，利用GPU完成通用計(jì)算的研究逐漸活躍起來(lái)，將GPU用于圖形渲染以外領(lǐng)域的計(jì)算成為GPGPU(General Purpose compuTIng on graphics processing units，基于GPU的通用計(jì)算)。而與此同時(shí)CPU則遇到了一些障礙，CPU為了追求通用性，將其中大部分晶體管主要用于構(gòu)建控制電路(比如分支預(yù)測(cè)等)和Cache，只有少部分的晶體管來(lái)完成實(shí)際的運(yùn)算工作。

CPU + GPU 是一個(gè)強(qiáng)大的組合，因?yàn)?CPU 包含幾個(gè)專為串行處理而優(yōu)化的核心，而 GPU 則由數(shù)以千計(jì)更小、更節(jié)能的核心組成，這些核心專為提供強(qiáng)勁的并行性能而設(shè)計(jì)。程序的串行部分在 CPU 上運(yùn)行，而并行部分則在 GPU上運(yùn)行。GPU 已經(jīng)發(fā)展到成熟階段，可輕松執(zhí)行現(xiàn)實(shí)生活中的各種應(yīng)用程序，而且程序運(yùn)行速度已遠(yuǎn)遠(yuǎn)超過(guò)使用多核系統(tǒng)時(shí)的情形。未來(lái)計(jì)算架構(gòu)將是并行核心 GPU 與多核 CPU 共同運(yùn)行的混合型系統(tǒng)。

一、CPU多核轉(zhuǎn)到GPU并行化(適合算術(shù)密集型)

雖然GPU并不適用于所有問(wèn)題的求解，但是我們發(fā)現(xiàn)那些對(duì)運(yùn)算力量耗費(fèi)巨大的科學(xué)命題都具備天然的“”特色。這類程序在運(yùn)行時(shí)擁有極高的運(yùn)算密度、并發(fā)線程數(shù)量和頻繁地存儲(chǔ)器訪問(wèn)，無(wú)論是在音頻處理、視覺(jué)仿真還是到分子動(dòng)力學(xué)模擬和金融風(fēng)險(xiǎn)評(píng)估領(lǐng)域都有大量涉及。這種問(wèn)題如果能夠順利遷移到GPU為主的運(yùn)算環(huán)境中，將為我們帶來(lái)更高效的解決方案。

傳統(tǒng)意義上的GPU不善于運(yùn)行分支代碼，但是ATI和NVIDIA經(jīng)過(guò)長(zhǎng)期改進(jìn)其內(nèi)部架構(gòu)已經(jīng)使得GPU可以較為高效地運(yùn)行分支、循環(huán)等復(fù)雜代碼。同時(shí)因?yàn)镚PU屬于并行機(jī)范疇，相同的運(yùn)算可以應(yīng)用到每個(gè)數(shù)據(jù)元素的時(shí)候，它們可以達(dá)到最好的性能。在CPU編程環(huán)境中，寫出每個(gè)輸入數(shù)據(jù)元素有不同數(shù)量的輸入的程序很容易，但在GPU這種并行機(jī)上還是有不少麻煩。

通用的數(shù)據(jù)結(jié)構(gòu)正是GPU編程的最大困難之一。CPU程序員經(jīng)常使用的數(shù)據(jù)結(jié)構(gòu)如列表和樹(shù)在GPU身上并不容易實(shí)現(xiàn)。GPU目前還不允許任意存儲(chǔ)器訪問(wèn)，而且GPU運(yùn)算單元的設(shè)計(jì)為主要操作是在表現(xiàn)位置和顏色的四維向量上。

不過(guò)這些并不能阻擋GPU編程的加速發(fā)展，因?yàn)镚PU不是真的為通用計(jì)算而設(shè)計(jì)的，需要一些努力才能讓GPU高速地服務(wù)通用計(jì)算程序。這些努力前些年是程序員而單獨(dú)實(shí)現(xiàn)的，而隨著ATI和NVIDIA開(kāi)始看到高性能計(jì)算市場(chǎng)的硬件需求，我們看到無(wú)論是Fermi架構(gòu)添加全能二級(jí)緩存和統(tǒng)一定址還是RV870架構(gòu)不斷優(yōu)化LDS并放大并發(fā)線程數(shù)，這些都是GPU自身硬件體系為了適應(yīng)未來(lái)的運(yùn)算環(huán)境而做出的變革。

二、并行化編程優(yōu)點(diǎn)

在GPU并行編程過(guò)程中，OpenCL是一個(gè)不錯(cuò)的選擇。OpenCL是Open CompuTIng Language(開(kāi)放式計(jì)算語(yǔ)言)的簡(jiǎn)稱，它是第一個(gè)為異構(gòu)系統(tǒng)的通用并行編程而產(chǎn)生的統(tǒng)一的、免費(fèi)的標(biāo)準(zhǔn)。OpenCL支持由多核的CPU、GPU、Cell類型架構(gòu)以及信號(hào)處理器(DSP)等其他的并行設(shè)備組成的異構(gòu)系統(tǒng)。OpenCL的出現(xiàn)，使得軟件開(kāi)發(fā)人員編寫高性能服務(wù)器、桌面計(jì)算系統(tǒng)以及手持設(shè)備的代碼變得更加快捷。OpenCL由用于編寫內(nèi)核程序的語(yǔ)言和定義并控制平臺(tái)的API組成，提供了基于任務(wù)和基于數(shù)據(jù)的兩種并行計(jì)算機(jī)制，使得GPU的計(jì)算不在僅僅局限于圖形領(lǐng)域，而能夠進(jìn)行更多的并行計(jì)算。但是，如果通過(guò)傳統(tǒng)的方法開(kāi)發(fā)一個(gè)能夠運(yùn)行在異構(gòu)平臺(tái)(在CPU和GPU的平臺(tái))的程序是很難的。不同的廠商，不同的產(chǎn)品型號(hào)的GPU一般有著不一樣的架構(gòu)，這樣要想開(kāi)發(fā)出一款能夠高效的能夠運(yùn)用不同平臺(tái)的所有計(jì)算資源的軟件是很難的。OpenCL的出現(xiàn)有效地解決了異構(gòu)平臺(tái)的問(wèn)題。

OpenCL規(guī)范是由Khronos Group推出的，OpenCL程序不僅僅可以運(yùn)行在多核的CPU上，也可以在GPU上進(jìn)行執(zhí)行，這充分體現(xiàn)了OpenCL的跨平臺(tái)性和可移植性，也讓編程人員可以充分利用GPU的強(qiáng)大的并行計(jì)算能力，相對(duì)于CPU來(lái)說(shuō)，GPU存在很多特點(diǎn)。

l GPU擁有的核心的數(shù)量要比高端CPU的核心數(shù)量多很多。雖然GPU的每個(gè)運(yùn)算核心沒(méi)有CPU的每個(gè)運(yùn)算核心工作頻率高，但是GPU的總體性能-芯片面積比以及性能-功耗比比CPU高很多，所以在處理越多線程的并行計(jì)算的任務(wù)性能高很多。

l GPU能夠通過(guò)大量并行線程之間的交織運(yùn)行隱藏全局的延遲，除此之外GPU還擁有大量的寄存器、局部存儲(chǔ)器和cache等用來(lái)提升外部存儲(chǔ)的訪問(wèn)性能。

l 在傳統(tǒng)的CPU運(yùn)算中，線程之間的切換是需要很大的開(kāi)銷的，所以在開(kāi)啟了大量線程的算法的效率是很低的。但是，在GPU中，線程之間的切換是很廉價(jià)的。

l GPU的計(jì)算能力比CPU強(qiáng)很多。

三、OpenCL環(huán)境下并行化編程

OpenCL是一個(gè)開(kāi)放的工業(yè)標(biāo)準(zhǔn)，它可以為CPU和GPU等不同的設(shè)備組成的異構(gòu)平臺(tái)進(jìn)行編程。OpenCL是一種語(yǔ)言，也是一個(gè)為并行編程而提供的框架，編程人員可以利用OpenCL編寫出一個(gè)能夠在GPU上執(zhí)行的通用程序。

OpenCL的技術(shù)核心包好了下面的四種模型：

l 平臺(tái)模型(Platform Model)：OpenCL平臺(tái)模型定義了主機(jī)和設(shè)備的角色，為程序員寫在設(shè)備上執(zhí)行的OpenCL C函數(shù)(內(nèi)核)提供了一個(gè)抽象的硬件模型。平臺(tái)模型確定了主機(jī)上的處理器能夠協(xié)調(diào)執(zhí)行，而且存在一個(gè)或者多個(gè)處理器能夠執(zhí)行OpenCL C代碼(設(shè)備)。

l 執(zhí)行模型(Execution Model)：定義如何在主機(jī)上配置OpenCL環(huán)境以及內(nèi)核(kernel)是如何在設(shè)備上執(zhí)行的。這其中包括在主機(jī)上設(shè)置OpenCL上下文，提供主機(jī)和設(shè)備交互的機(jī)制，定義了內(nèi)核在設(shè)備上執(zhí)行的兵法模式。

l 內(nèi)存模型(Memory Model)：定義了內(nèi)核使用的抽象的內(nèi)存層次。

l 編程模型(Programming Model)：定義了并發(fā)模型如何讓映射到物理硬件。

OpenCL框架被分成平臺(tái)層API和運(yùn)行時(shí)API，平臺(tái)層API允許應(yīng)用查詢平臺(tái)和設(shè)備，而且可以通過(guò)上下文來(lái)管理它們。運(yùn)行時(shí)的API利用上下文去管理設(shè)備上的內(nèi)核的執(zhí)行。

四、OpenCL并行化調(diào)試工具

在利用OpenCL進(jìn)行編程之后，我們可以使用gDEBugger進(jìn)行調(diào)試，gDEBugger是一個(gè)高級(jí)的OpenCL和OpenGL調(diào)試器，分析器和內(nèi)存分析器。它可以完成其他工具無(wú)法完成的工作：追蹤在OpenCL和OpenGL之上的應(yīng)用程序的活動(dòng)，并發(fā)現(xiàn)系統(tǒng)實(shí)現(xiàn)的內(nèi)部發(fā)生了什么。

程序員可以在以下的情況下使用gDEBugger

l 優(yōu)化OpenCL和OpenGL應(yīng)用程序性能。

l 快速找到與OpenCL和OpenGL相關(guān)的bug。

l 改善程序性能和魯棒性

五、CPU和GPU共享記憶體空間

在過(guò)去的時(shí)間，雖然GPU和CPU已整合到同一個(gè)晶片上(GPGPU技術(shù))，但是晶片在運(yùn)算時(shí)要定位記憶體的位置仍然得經(jīng)過(guò)繁雜的步驟，這是因?yàn)镃PU和GPU的記憶體池仍然是獨(dú)立運(yùn)作。之前為了解決兩者記憶體池獨(dú)立的運(yùn)算問(wèn)題，當(dāng)CPU程式需要在GPU上進(jìn)行部分運(yùn)算時(shí)，CPU都必須從CPU的記憶體上復(fù)制所有的資料到GPU的記憶體上，而當(dāng)GPU上的運(yùn)算完成時(shí)，這些資料還得再?gòu)?fù)制回到CPU記憶體上。這些步驟都會(huì)不斷耗費(fèi)時(shí)間以及程式處理的效能。2012年，AMD就攜手ARM、高通、三星、聯(lián)發(fā)科等廠商成立HSA(Heterogeneous Systems Architecture)基金會(huì)，希望拓展CPU和GPU協(xié)同運(yùn)算的新架構(gòu)，并輔助此架構(gòu)發(fā)展的異質(zhì)運(yùn)算新軟體開(kāi)發(fā)環(huán)境。

日前，AMD進(jìn)一步公開(kāi)說(shuō)明此運(yùn)算架構(gòu)的新技術(shù)：hUMA(heterogeneous Uniform Memory Access)。透過(guò)hUMA，CPU和GPU能共享同一個(gè)記憶體空間，并且CPU能夠直接存取GPU的記憶體位址，不必像過(guò)去得花工夫再將GPU的運(yùn)算資料復(fù)寫到CPU上。近日，在HotChips會(huì)議上，AMD連續(xù)公布了桌面FX處理器使用的Steamroller架構(gòu)、面向低功耗平臺(tái)的Jaguar架構(gòu)等，但是這都不是AMD的終極目標(biāo)，他們聲稱處理器速度的競(jìng)爭(zhēng)已經(jīng)結(jié)束，未來(lái)屬于HSA。

六、未來(lái)發(fā)展趨勢(shì)

在計(jì)算機(jī)發(fā)展歷程中，為了解決各種特定的問(wèn)題，不斷有互不兼容的計(jì)算模塊被加入系統(tǒng)，卻很少?gòu)娜謨?yōu)化的角度加以考察。計(jì)算機(jī)整體效率不高的現(xiàn)狀正是這種設(shè)計(jì)模式的直接后果。常見(jiàn)情況是軟件的計(jì)算負(fù)載被調(diào)度在一個(gè)并不適合當(dāng)前任務(wù)的計(jì)算設(shè)備上低效執(zhí)行。HSA則展現(xiàn)了一種全新的體系架構(gòu)，可以適應(yīng)各種特性的計(jì)算任務(wù)。

HSA版本可以在CPU和GPU之間無(wú)縫地共享數(shù)據(jù)，而無(wú)需內(nèi)存拷貝和緩存刷新，因?yàn)槿蝿?wù)以極低的開(kāi)銷被調(diào)度到合適的處理器上。最終的結(jié)果是HSA版本的性能高出2.3倍，而功耗降低2.4倍*。相較而言，無(wú)論是多核CPU、GPU、甚至非HSA方式的混合CPU和GPU都無(wú)法達(dá)到這樣的性能水平。同樣重要的是，無(wú)需轉(zhuǎn)換到迥異的編程模型，僅僅通過(guò)C++的簡(jiǎn)單擴(kuò)展就可以實(shí)現(xiàn)程序。