胡玉貴

摘要：隨著越來(lái)越多的公司和企業(yè)使用GPU來(lái)作為加速計(jì)算設(shè)備，對(duì)并行程序的需求也越來(lái)越大，目前我們一般都使用CUDA或OPENCL等底層API進(jìn)程序開發(fā)，但是使用這些底層API來(lái)進(jìn)行開發(fā)效率都不高，目前出現(xiàn)OPENACC指令就是針對(duì)這個(gè)問題提出來(lái)的，在該文里，我們針對(duì)高斯模糊算法，分別使用CPU，OPENACC，CUDA進(jìn)行實(shí)現(xiàn)，比較他們的效率，發(fā)現(xiàn)在雖然OPENACC相對(duì)于CUDA性能要低一些，但相對(duì)其陡峭的學(xué)習(xí)曲線和低下的開發(fā)效率，OPENACC有著不錯(cuò)的性價(jià)比，而且隨著編譯器和硬件技術(shù)的發(fā)展，OPENACC有著廣闊的發(fā)展空間。

關(guān)鍵詞：OPENACC；CUDA；GPGPU；卷積

中圖分類號(hào)：TP391 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044（2012）34-8248-03

1簡(jiǎn)介

隨著性價(jià)比的日益提高，包含加速設(shè)備的異構(gòu)計(jì)算系統(tǒng)越來(lái)越受到歡迎，但是，由于復(fù)雜的代碼設(shè)計(jì)或是只能特定于廠商設(shè)備，使得底層的API來(lái)進(jìn)行GPU的軟件開發(fā)困難重重，所以對(duì)于開發(fā)大型軟件或項(xiàng)目來(lái)說(shuō)，這樣一個(gè)沒有效率和高度依賴設(shè)備廠商的開發(fā)過(guò)程是不可接受的。

目前已經(jīng)出現(xiàn)了一些方法，即采有基于指導(dǎo)的高層API來(lái)轉(zhuǎn)移這些底層代碼由編譯器實(shí)現(xiàn)，當(dāng)然，從一般意義來(lái)說(shuō)，這并沒有簡(jiǎn)化程序的并行化設(shè)計(jì)，還是要由程序員來(lái)負(fù)責(zé)挖掘代碼中的并行功能，但是這大大提高了程序的開發(fā)效率和代碼的可維護(hù)性，而且，將幾種指令加速進(jìn)行標(biāo)準(zhǔn)化將使代碼跨設(shè)備并行化成為可能，在2011年12月，一群OPENMP的成員同時(shí)推出了OPENACC，這些成員包括CAPS，CRAY，NVIDIA，PGI等公司，它將C/C++或FORTAN中的循環(huán)部分計(jì)算轉(zhuǎn)移到加速設(shè)備中，在該文中，我們使用高斯模糊算法來(lái)體驗(yàn)OPENACC指令，并把它與CPU，CUDA進(jìn)行比較分析，并結(jié)合代碼進(jìn)行綜合分析。

2相關(guān)的工作

GPU的通用化設(shè)計(jì)帶來(lái)了新的編程模式的巨大改變，目前，主要的GPU編程模型為CUDA[13]和OPENCL[10]，二者都是使用GPU核函數(shù)來(lái)發(fā)揮GPU加速器的威力，當(dāng)然，CUDA只適用于NVIDIA的GPU，而OPENCL則是作為一個(gè)標(biāo)準(zhǔn)適用于多個(gè)廠商的硬件設(shè)備，由于底層代碼的重復(fù)性和易錯(cuò)性，用這些API進(jìn)行開發(fā)通常效率很低。目前，已經(jīng)提出了幾個(gè)基于制導(dǎo)指令的加速計(jì)算協(xié)議，類似于OPENMP的指令制導(dǎo)模型，OPENACC也是于加速某個(gè)代碼區(qū)域的加速編程模型.

ThePortlandGroup提供了應(yīng)用于C和Fortan語(yǔ)言的PGI加速模型，這個(gè)模型除了提供基于指令制導(dǎo)的編譯器輔助加速之外，還附加一系列的附加功能，而CAPS公司建立的HMPP環(huán)境則是用指令產(chǎn)生一系列的代碼片段，這些片段可用于許多硬件設(shè)備上進(jìn)行加速。hiCUDA則使用核心指令，數(shù)據(jù)傳輸條件和函數(shù)調(diào)用定義了一個(gè)高層的CUDA抽象，除了支持CUDA規(guī)范，hiCUDA比OPENACC給了程序員更多的工作和責(zé)任，OPENMPC則可以將OPENMP的代碼翻譯成CUDA代碼。

3openacc總述

在為不同系統(tǒng)，主機(jī)CPU和加速設(shè)備提供可移植的同時(shí)，用于C/c++和fORTAN的OpenAcc指令把低層GPU編程的工作轉(zhuǎn)移給編譯器，但是，到目前為止，已經(jīng)實(shí)現(xiàn)的OPENACC僅僅支持NVIDIAGPU，在這里，我們對(duì)OPENACC作一個(gè)簡(jiǎn)述。

OPENACCAPI基于一個(gè)主機(jī)模型，在這個(gè)主機(jī)模型里，主程序運(yùn)行在主機(jī)里，而且計(jì)算緊密區(qū)域則會(huì)加載到附屬的加速設(shè)備上去，內(nèi)存模型則分為主機(jī)和設(shè)備二層，而且二者之間并不同步。執(zhí)行和數(shù)據(jù)管理一般由OPENACC來(lái)標(biāo)定，下面是一些基本指令介紹

最重要的指令是parallel和kernels指令，這二個(gè)指令描述了同步或異步的執(zhí)行區(qū)域，因?yàn)閗ernels目前的實(shí)現(xiàn)都有些問題，這里我們重點(diǎn)放在parallel指令介紹，parallel包圍著的代碼區(qū)域?qū)?yīng)著能以隊(duì)排運(yùn)行OPENCL的核函數(shù)，為了提高性能，我們還可以使用gangs關(guān)鍵詞，對(duì)應(yīng)著worker或vector_length的長(zhǎng)度，關(guān)鍵詞gang和vector則對(duì)應(yīng)工作組及在工作組里的工作項(xiàng)，在OPENCL里，worker定義了某些工作項(xiàng)的組合，類似于CUDA里warp的概念，在parallel區(qū)域里，loop關(guān)鍵詞則表明了在加速器里工作項(xiàng)的共享項(xiàng)，編程者也可以插入另外的語(yǔ)句在parallel，kernels或是loop關(guān)鍵詞來(lái)優(yōu)化或是數(shù)據(jù)管理

4openacc實(shí)現(xiàn)卷積

卷積是在各種實(shí)際問題的實(shí)踐中，例如：統(tǒng)計(jì)學(xué)中加權(quán)的滑動(dòng)平均；物理學(xué)中任何一個(gè)線性系統(tǒng)（符合疊加原理）；聲學(xué)中回聲由源聲與各種反射效應(yīng)表達(dá)；電子工程與信號(hào)處理中線性系統(tǒng)的輸出由輸入信號(hào)與系統(tǒng)的沖激響應(yīng)表達(dá)；概率論中兩個(gè)統(tǒng)計(jì)獨(dú)立的概率密度，等等的需要而產(chǎn)生，因此，使用GPU計(jì)算卷積具有重要的意義。

4.1基于OPENACC的卷積加速算法

5數(shù)據(jù)結(jié)果分析

實(shí)驗(yàn)平臺(tái)操作系統(tǒng)為redhatfedora64位linux系統(tǒng)，CPU為I7-2600，主頻3.4G，內(nèi)存為16G，顯卡為NIVIDATELSAC2070，所采用的編譯軟件為HMPP3.2，支持OPENACC的部分指令。

圖1為不同像素的圖像下三種方法卷積算法的性能比較，從中我們可以看出，隨著圖像卷積像素的增大，CPU的計(jì)算時(shí)間呈指數(shù)性增長(zhǎng)，而在其代碼中加入OPENACC指令后，其消耗的時(shí)間則為線性的時(shí)間，而經(jīng)CDUA優(yōu)化的代碼，比OPENACC則要小6倍左右，但是我們要指出，雖然CUDA性能比OPENACC好，但是這是經(jīng)過(guò)精心優(yōu)化，而且需要有豐富經(jīng)驗(yàn)的程序員才能實(shí)現(xiàn)，而OPENACC只要加入十幾行代碼，就比串行代碼有十倍左右的性能提升，而且隨著編譯器技術(shù)和硬件的發(fā)展，OPENACC與CUDA，OPENCL等底層技術(shù)的差距將會(huì)越來(lái)越小。

6結(jié)論

使用不多的openacc指令，在原有代碼的基礎(chǔ)上，我們就可以得加速比良好的卷積算法，且不用改變?cè)瓉?lái)代碼，大大增強(qiáng)了代碼了維護(hù)性和可讀性，當(dāng)然，對(duì)于當(dāng)前的卷積實(shí)現(xiàn)來(lái)說(shuō)，使用OPENACC指令優(yōu)化還有很大的空間，但對(duì)于目前已有大量的串行代碼，采用OPENACC指令可以將其運(yùn)行在GPU設(shè)備上，實(shí)現(xiàn)并行加速。

參考文獻(xiàn)：

[1]BordawekarR，BondhugulaU，RaoR.CanCPUsMatchGPUsonPerformancewithProductivity？：ExperienceswithOptimizingaFLOP-intensiveApplicationonCPUsandGPU.Technicalreport，IBMRes.Division，2010.

[2]BrecherC，GorgelsC，HardjosuwitoA.SimulationbasedToolWearAnalysisinBevelGearCutting.InternationalConferenceonGears，volume2108.2ofVDI-Berichte，pages1381–1384，usseldorf，2010.VDIVerlag.

[3]M.B¨ucker，R.Beucker，andA.Rupp.ParallelMinimump-NormSolutionoftheNeuromagneticInverseProblemforRealisticSignalsUsingExactHessian-VectorProducts.SIAMJournalonScientificComputing，2008，30（6）：2905-2921.

[4]DolbeauR，BihanS，BodinF.HMPP：AHybridMulti-coreParallelProgrammingEvironment.InFirstWorkshoponGeneralPurposeProcessingonGraphicsProcessingUnits，2007.

[5]CAPSEnterprise，CrayInc.，NVIDIA，andthePortlandGroup.TheOpenACCApplicationProgrammingInterface，v1.0，2011.