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

CPU + GPU 是一個強(qiáng)大的組合，因?yàn)?CPU 包含幾個專為串行處理而優(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)超過使用多核系統(tǒng)時的情形。未來計(jì)算架構(gòu)將是并行核心 GPU 與多核 CPU 共同運(yùn)行的混合型系統(tǒng)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

l 平臺模型（Platform Model）：OpenCL平臺模型定義了主機(jī)和設(shè)備的角色，為程序員寫在設(shè)備上執(zhí)行的OpenCL C函數(shù)（內(nèi)核）提供了一個抽象的硬件模型。平臺模型確定了主機(jī)上的處理器能夠協(xié)調(diào)執(zhí)行，而且存在一個或者多個處理器能夠執(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框架被分成平臺層API和運(yùn)行時API，平臺層API允許應(yīng)用查詢平臺和設(shè)備，而且可以通過上下文來管理它們。運(yùn)行時的API利用上下文去管理設(shè)備上的內(nèi)核的執(zhí)行。

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

在利用OpenCL進(jìn)行編程之后，我們可以使用gDEBugger進(jìn)行調(diào)試，gDEBugger是一個高級的OpenCL和OpenGL調(diào)試器，分析器和內(nèi)存分析器。它可以完成其他工具無法完成的工作：追蹤在OpenCL和OpenGL之上的應(yī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共享記憶體空間

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

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

六、未來發(fā)展趨勢

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

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