基于MPI的GPU集群并行通信系統(tǒng)實現(xiàn)

侯景德 陳慶奎,2 趙海燕

基于MPI的GPU集群并行通信系統(tǒng)實現(xiàn)

侯景德1陳慶奎1,2趙海燕1

1(上海理工大學(xué)光電信息與計算機工程學(xué)院 上海 200093)

2(上海市現(xiàn)代光學(xué)系統(tǒng)重點實驗室 上海 200093)

針對GPU和MPI混合編程本身的復(fù)雜性問題，提出基于MPI的GPU并行通信系統(tǒng)：動態(tài)管道緩沖池體系(Pipe Dynamic Buffer Pool)。描述PDBP的主要部件、體系結(jié)構(gòu)和實現(xiàn)過程，定義通信協(xié)議。該系統(tǒng)采用動態(tài)管道池和動態(tài)緩沖池技術(shù)，對MPI并行通信進行擴展，為CUDA程序員提供簡易高效的通信編程接口。實驗表明，PDBP具有較高的并行通信效率，特別是在多對多通信模式下，通信效率提高了近9倍。

MPI 動態(tài)管道池 動態(tài)緩沖池 通信協(xié)議 PDBP

0 引 言

近年來，3D、物聯(lián)網(wǎng)技術(shù)、移動互聯(lián)網(wǎng)技術(shù)、4G等應(yīng)用逐步展開。這些新技術(shù)的廣泛應(yīng)用帶來了海量信息處理問題以及如何提高大規(guī)模實時支持能力的新挑戰(zhàn)。

GPU集群具有大規(guī)模并行多核結(jié)構(gòu)、多線程浮點運算的高吞吐量及使用大型片上緩存顯著減少大量數(shù)據(jù)移動的時間[1-3]。GPU集群比傳統(tǒng)CPU集群具有更好的成本效益[4-6]，不僅在速度性能上有巨大飛躍，而且顯著降低空間、能源以及冷卻的要求[7-10]。總之，GPU集群為應(yīng)對這些新挑戰(zhàn)帶來了新的曙光。

然而，GPU集群并行編程并未出現(xiàn)一個標(biāo)準(zhǔn)通信模型，絕大多數(shù)集群應(yīng)用采取CUDA與MPI混合編程的方法[11,12]。CUDA具有獨立編譯系統(tǒng)，無法和MPI編譯系統(tǒng)融合[13,14]，因而開發(fā)二者混合系統(tǒng)為CUDA程序員帶來了困難。需要了解GPU硬件架構(gòu)和MPI消息傳遞機制，顯式控制內(nèi)存與顯存、節(jié)點與節(jié)點間的數(shù)據(jù)傳輸[15]。因此，對CUDA編程人員來說，GPU集群并行編程仍是一個復(fù)雜問題。

為了解決上述問題，本文提出基于MPI的GPU集群并行通信系統(tǒng)PDBP的實現(xiàn)。該系統(tǒng)構(gòu)建動態(tài)管道池和動態(tài)緩沖池來實現(xiàn)各類進程、線程之間的通信通道，定義PDBP內(nèi)各個模塊間交互的通信協(xié)議，以實現(xiàn)消息的高效傳輸，并且向外提供統(tǒng)一的通信函數(shù)接口。CUDA程序員在進行GPU和MPI混合編程時，無需了解MPI通信細(xì)節(jié)，只需調(diào)用相應(yīng)通信函數(shù)，便可以進行并行GPU程序開發(fā)。使CUDA程序員從MPI編程的繁瑣細(xì)節(jié)中解放出來，更加關(guān)注于上層業(yè)務(wù)算法的設(shè)計，顯著改善GPU和MPI混合編程的效率。同時，由于動態(tài)緩沖池機制對MPI的擴展，極大地提高了MPI并發(fā)多數(shù)據(jù)流通信的效率。

1 GPU集群并行通信系統(tǒng)框架

集群通信環(huán)境CCE(Cluster Communication Environment)為四元組CCE。其中CNodes = {CNode1, CNode2, …, CNoden}是計算節(jié)點的集合，計算節(jié)點配有CPU和流處理器GPU計算資源，其支持通用C語言和流處理器程序開發(fā)環(huán)境CUDA或CTM(Close To Metal)；MNode是主控節(jié)點，負(fù)責(zé)管理CNode、集群通信初始化以及作業(yè)調(diào)度等；Net是互連網(wǎng)絡(luò)，其上配有MPI通信環(huán)境；CS為通信軟件的集合，包括MPICH、PDBP等。

廣義進程為四元組GP。其中，PName為進程名；PriPipe為私有管道；RDPThread為讀管道線程，WRPThread為寫管道線程；CThreads = {CT1, CT2,…, CTn}是一系列計算線程的集合，一般由用戶根據(jù)其業(yè)務(wù)邏輯編寫。

廣義進程類似于通常意義上的進程，不同之處主要是，每個GP都配備有兩個管道和兩個線程。一個管道用于向其他GP發(fā)送數(shù)據(jù)，另一個管道用于接收其它GP發(fā)來的數(shù)據(jù)，與兩個管道相對應(yīng)的有寫管道線程(WRPThread)和讀管道的線程(RDPThread)。按照是否與流處理器相關(guān)來劃分，廣義進程又被分為正常廣義進程NGP(Normal Generalized Process)和流處理計算廣義進程SGP(Stream Generalized Process)。流處理計算廣義進程是涉及到流處理計算設(shè)備和開發(fā)環(huán)境(如CUDA、CTM)的進程，而NGP則為只涉及CPU環(huán)境運行的進程。

2 PDBP模型

管道動態(tài)緩沖池模型為五元組PDBP。其中，DPP為動態(tài)管道池，DDBP為動態(tài)雙緩沖池，CPI為通信編程接口，MESP為消息協(xié)議。PDBP的總體結(jié)構(gòu)如圖1所示。

圖1 PDBP總體結(jié)構(gòu)圖

2.1 動態(tài)管道池模型

這里所說的管道是一個單項流動的數(shù)據(jù)流通道，類似于UNIX操作系統(tǒng)中的管道。

動態(tài)管道池DPP是進程NGP之間、進程SGP之間以及進程NGP與進程SGP之間的通信的通道。它隱藏了進程NGP和SGP的差異性，對收發(fā)的消息分別進行統(tǒng)一封裝。

動態(tài)管道池模型為五元組DPP。其中PP為管道池；GP-Tab 為廣義進程表；PP={PubPipe, PriPipe}，一般PP由一個“公共管道”(PubPipe)和多個“私有管道”(PriPipe)組成。PubPipe主要是用來收集本主機中所有GP發(fā)送的數(shù)據(jù)消息的“公共信箱”，即當(dāng)一個GP要向其他GP發(fā)送數(shù)據(jù)消息時，它只需啟動其WRPThread向“公共信箱”寫入數(shù)據(jù)消息即可，而無需參與和知曉消息發(fā)送的過程細(xì)節(jié)。PriPipe主要是本機GP接收其他GP數(shù)據(jù)消息的“私有信箱”，即當(dāng)一個GP要接收來自其它GP的數(shù)據(jù)消息時，它只需啟動其RDPThread從“私有信箱”讀取數(shù)據(jù)消息即可，也無需參與和知曉消息接收的過程細(xì)節(jié)。

如果為每個GP都分配一個PriPipe，并且在其生命周期內(nèi)一直獨占此管道，顯然會增大系統(tǒng)資源的開銷和降低資源的利用率。因此GP與PriPipe采用動態(tài)綁定的方式。當(dāng)一個GP需要進行與其他GP進行通信時，GP向“管道管理器”PM申請綁定一個PriPipe，PM查看“管道資源表”Pipe-Tab，將“管道池”PP中的某個處于“空閑”的管道分配給GP，并更新“管道進程綁定表” GP-Pipe-Bind-Tab；當(dāng)GP通信結(jié)束后需釋放其分配的PriPipe，歸還到PP中。DPP結(jié)構(gòu)如圖2所示。

圖2 DPP結(jié)構(gòu)圖

2.2 動態(tài)雙緩沖池模型

為對MPI并行通信進行擴展以提高并發(fā)多數(shù)據(jù)流的通信效率，在通信的每臺主機內(nèi)都設(shè)置一個發(fā)送緩沖池和一個接受緩沖池，并且緩沖池配有線程池，以提高收發(fā)消息的高度并行性。

動態(tài)雙緩沖池模型為九元組DDBP。其中SBP為發(fā)送緩沖池，RBP為接收緩沖池，UMB為用戶內(nèi)存塊，SBPInfo-Tab為維護發(fā)送緩沖池信息的數(shù)據(jù)結(jié)構(gòu)，RBPInfo-Tab為維護接收緩沖池信息的數(shù)據(jù)結(jié)構(gòu)，UMBInfo-Tab為維護用戶內(nèi)存塊信息的數(shù)據(jù)結(jié)構(gòu)，HOSTInfo-Tab 為主機信息表，MainThread為主線程，負(fù)責(zé)DDBP的初始化及線程調(diào)度等，ThreadPool為對緩沖池進行讀寫的線程池。DDBP的結(jié)構(gòu)如圖3所示。

圖3 DDBP結(jié)構(gòu)圖

2.3 發(fā)送/接收緩沖池

SBP是緩沖發(fā)往遠(yuǎn)端各個主機消息的動態(tài)環(huán)形緩沖池。其中SM為發(fā)送矩陣，SMB為SM所占用的內(nèi)存塊的集合。RBP是緩沖從遠(yuǎn)端各個主機接收到的消息的動態(tài)環(huán)形緩沖池。其中RM為接收矩陣，RMB為RM所占用的內(nèi)存塊的集合。

SM/RM都是一個M(N矩陣，其中M代表當(dāng)前通信域中主機的個數(shù)，分別稱SM、RM的第i行為發(fā)送子緩沖池SCBPi、接收子緩沖池RCBPi。其中0≤i≤M-1，N代表每個子緩沖池的最大容量，可以根據(jù)通信數(shù)據(jù)流的特點來調(diào)整N的大小。當(dāng)前主機的SCBPi是用于向遠(yuǎn)端主機i發(fā)送數(shù)據(jù)的緩沖池，當(dāng)前主機的RCBPj是用于存儲從遠(yuǎn)端主機j接收到的數(shù)據(jù)的緩沖池。假設(shè)HostA、HostB為當(dāng)前通信域中任意兩臺主機，若主機HostA要向主機HostB發(fā)送數(shù)據(jù)，則只需將HostA的SCBPB中的數(shù)據(jù)發(fā)往主機HostB，HostB將接收的數(shù)據(jù)存儲在本機的RCBPA中。

2.4 用戶內(nèi)存塊UMB

UMB是DDBP向操作系統(tǒng)申請的內(nèi)存塊的集合，每個內(nèi)存塊都有一個唯一的標(biāo)示符blockId且大小都相同。UMB為SMB和RMB所共享，UMBInfo-Tab是維護UMB信息的數(shù)據(jù)結(jié)構(gòu)。

SM和RM中的元素并不是實際存儲數(shù)據(jù)的物理內(nèi)存塊，而是UMB中的內(nèi)存塊的標(biāo)志blockId。因此稱SM和RM的地址空間為邏輯地址空間LAS(Logical Address Space)。邏輯地址空間保證了SM和RM并行發(fā)送/接收數(shù)據(jù)時結(jié)構(gòu)上的整齊性，為實現(xiàn)消息整列的并行發(fā)送/接收提供了結(jié)構(gòu)支持。

稱UMB的地址空間為物理地址空間PAS(Physical Address Space)。如果邏輯地址空間中某元素已經(jīng)分配了物理地址空間中某內(nèi)存塊的blockId，則稱此元素為“實元素”RE(Real Elements)，否則稱為“虛元素”VE(Virtual Elements)。邏輯地址與物理地址的映射關(guān)系及相應(yīng)的UMBInfo-Tab如圖4所示。

圖4 邏輯地址LAS與物理地址PAS映射關(guān)系

稱邏輯地址空間中連續(xù)的RE形成的空間為實空間RS(Real Space)，稱邏輯地址空間中連續(xù)的VE形成的空間為虛空間VS(Virtual Space)。稱實空間與虛空間臨界處的實元素為臨界實元素CRE(Critical Real Elements)，稱實空間與虛空間臨界處的虛元素為臨界虛元素CVE(Critical Virtual Elements)，如圖5所示。

圖5 實空間RS與虛空間VS

2.5 基于閾值的UMB分配算法

稱SCBPi或RCBPi中實元素數(shù)目(‖REi‖)與元素總數(shù)目的比值，為該SCBPi或RCBPi的密度因子DFi(Density Factor)，如下式：

(1)

稱SCBPi或RCBPi中已用實空間大小與當(dāng)前子緩沖池實際可用實空間大小的比值，為該SCBPi或RCBPi實空間利用率SUi(Space utilization)，如下式:

(2)

其中recv、send分別為當(dāng)前子緩沖池的接收、發(fā)送位置指針(下同)。

稱SCBPi或RCBPi中已用實空間大小與未用實空間的比值，為該SCBPi或RCBPi收發(fā)速度比RSRi(Receive Send Ratio，簡稱RSR)，如下式：

(3)

閾值Threshold是基于實空間利用率SU的值，一般有0

基于閾值的UMB分配算法的基本思想：(1) 為當(dāng)前通信域中的每臺主機的SCBP和RCBP分配相同的實空間。(2) 對當(dāng)前SCBP/RCBP，每當(dāng)recv指針到達(dá)臨界實元素CRE時，計算其SU。如果SU大于閾值Threshold，則說明當(dāng)前SCBP/RCBP通信較為密集，那么就從位置臨界虛元素CVE開始為其增加實空間。(3) 實空間的增加量根據(jù)收發(fā)速度比RSR來確定，以使每個子緩沖池的收發(fā)速率與其可用空間達(dá)到平衡，避免因接收迅速而發(fā)送遲緩造成子緩沖池“滿”，導(dǎo)致數(shù)據(jù)溢出。

算法1 基于閾值的UMB分配算法

輸入：Threshold，UMBInfo-Tab，SCBPi/RCBPi

輸出：增加實空間后的SCBPi/RCBPi

/* 初始分配實空間 */

1. for i = 1 to n do

2. if(UMBInfo-Tab 尚有可用內(nèi)存塊)

3. Allocation_RS(SCBPi/RCBPi, m)

//為子緩沖池分配實空間，大小為m

4. else 輸出提示信息

5. end if

6. end for

/* 根據(jù)閾值Threshold動態(tài)調(diào)整實空間 */

7. for i = 1 to n do

8. if(SCBPi.recv或RCBPi.recv位于CRE)

9. 計算SCBPi/RCBPi的SUi

10. if((SUi> Threshold) && (DFi< 1) )

11. if(UMBInfo-Tab 尚有可用內(nèi)存塊)

12. 計算RSRi

13. m = (RSRi- 1)* curSize

14. Allocation_RS(SCBPi/RCBPi, m)

15. else 輸出提示信息

16. end if

17. end if

18. end if

19. end for

2.6 線程池ThreadPool

線程池為ThreadPool。其中RBP-WRT為RBP的寫線程，負(fù)責(zé)接收遠(yuǎn)端主機發(fā)來消息，并將消息寫入RBP；RBP-RDT為RBP的讀線程，從RBP中讀取消息，并將消息轉(zhuǎn)發(fā)到UDAP的PriPipe中。SBP-WRT為SBP的寫線程，負(fù)責(zé)讀取PM轉(zhuǎn)發(fā)過來的發(fā)往遠(yuǎn)程主機的消息，并將消息寫入對應(yīng)的SCBP中；SBP-RDT為SBP的讀線程，主要負(fù)責(zé)從SBP中的各個SCBP中讀取消息，并將消息并行發(fā)送至遠(yuǎn)端主機。

3 通信編程接口CPI

DDP和DDBP對GP來說是消息收發(fā)的服務(wù)者，GP若要收發(fā)消息只需調(diào)用DDP和DDBP提供的通信編程口CPI即可，主要接口有以下幾個：

進程注冊prcsReg(…);

進程申請管道prcsApplyPipe(…);

發(fā)送數(shù)據(jù)sendData(…);

接收數(shù)據(jù)recvData(…);

進程釋放管道prcsReleasePipe(…);

進程注銷prcsFree(…)。

4 消息協(xié)議MESP

在PDBP內(nèi)傳輸?shù)南?，主要有兩類：控制消息和?shù)據(jù)消息?？刂葡⒅饕姓埱?應(yīng)答消息，初始化消息和任務(wù)調(diào)度消息等，它們相對于數(shù)據(jù)消息具有實時性高、數(shù)據(jù)量小、發(fā)送和接收的進程是隨機的等特點，因此PDBP消息系統(tǒng)也分為兩部分，控制消息傳輸系統(tǒng)和數(shù)據(jù)消息傳輸系統(tǒng)。PDBP中的消息協(xié)議為MESP，其中CMP為系統(tǒng)中的控制消息協(xié)議集合，DMP為系統(tǒng)中的數(shù)據(jù)消息協(xié)議的集合。

設(shè)計消息協(xié)議MESP的基本思想：(1) 將消息分成消息頭和消息體兩部分。(2) 消息頭盡可能短，根據(jù)PDBP各個層次的結(jié)構(gòu)設(shè)計層次化的消息頭。(3) 將數(shù)據(jù)統(tǒng)一封裝在消息體中，消息體的大小通過參數(shù)可調(diào)整，以適應(yīng)長消息、短消息以及數(shù)據(jù)流消息通信的不同需要。

表1 協(xié)議格式參數(shù)

4.1 控制消息協(xié)議CMP

CMP主要是為解決系統(tǒng)之間各個部分相互協(xié)調(diào)以及MNode管理CNode而設(shè)計的，主要有以下幾種：

1) 請求消息URMsg

URMsg是GP向DPP發(fā)送的申請消息。URMsg根據(jù)type的不同可以分為GP申請注冊進程的消息RegMsg和申請管道的消息APipeMsg，申請釋放管道的消息ReleaseMsg以及注銷進程的消息CancelMsg。

2) 應(yīng)答消息DAMsg

DAMsg是DPP對GP申請消息的應(yīng)答消息。DAMsg根據(jù)type的不同可以分為RegMsg的應(yīng)答消息ARMsg及APipeMsg的應(yīng)答消息AAPMsg。

3) 初始化消息

初始化消息主要有兩大類：主機信息消息和進程管道綁定信息消息。

主機信息消息HInfoMsg，根據(jù)type的不同可以分為單機的主機信息S-HOSTInfo-Tab和當(dāng)前通信域中所有主機的主機信息的集合ALL-HOSTInfo-Tab。

進程管道綁定信息消息MBInfoMsg。根據(jù)type的不同可以分為單機的進程管道綁定信息S-BInfoMsg和當(dāng)前通信域中所有主機的進程管道綁定信息的集合ALL-MBInfoMsg。

4.2 利用CMP進行系統(tǒng)初始化

各臺主機根據(jù)業(yè)務(wù)邏輯編寫好各自的GP以后，就可以利用DBP和DDBP通信，但首先必須進行通信初始化，系統(tǒng)初始化的時序圖6所示。

圖6 PDBP初始化時序圖

4.3 數(shù)據(jù)消息協(xié)議DMP

DMP主要是為解決系統(tǒng)之間各個部分收發(fā)數(shù)據(jù)消息而設(shè)計的，主要有以下幾種：

UDataMsg是GP向DDP發(fā)送的數(shù)據(jù)消息。

LocalMsg是本地數(shù)據(jù)消息。

RemoteMsg是遠(yuǎn)程數(shù)據(jù)消息。

BPMsg是緩沖池數(shù)據(jù)消息。

4.4 遠(yuǎn)端消息傳輸

遠(yuǎn)端消息傳輸是指在不同主機之間傳輸數(shù)據(jù)消息，通常傳輸?shù)臄?shù)據(jù)量比較大。因此采用分層的數(shù)據(jù)包格式而非統(tǒng)一的數(shù)據(jù)包格式，不但最大限度地減小數(shù)據(jù)包包頭的長度，而且減小了數(shù)據(jù)包解析封裝的復(fù)雜性。同時提高了有效負(fù)載的傳輸效率，遠(yuǎn)端消息傳輸如圖7所示。

圖7 PDBP遠(yuǎn)端數(shù)據(jù)消息傳輸圖

5 實驗結(jié)果與分析

實驗主要測試各個不同節(jié)點SGP與SGP之間的通信，每對進行通信的SGP之間傳輸數(shù)據(jù)的規(guī)模均為64 GB，64 GB的數(shù)據(jù)由多個大小相同的單位數(shù)據(jù)包組成。為測得該系統(tǒng)本身傳輸速度的極限值以及排除磁盤讀寫速度的限制，發(fā)送方的數(shù)據(jù)由發(fā)送方SGP生成，傳輸?shù)浇邮辗絊GP后，并不進行存盤操作，只執(zhí)行簡單校驗工作。選取的通信模式均為主機SGP與SGP之間一對多、多對一和多對多模式，并在多對多模式下將PDBP與傳統(tǒng)MPI全互換的吞吐量進行對比。每種通信模式下選取的自變量主要是單位數(shù)據(jù)包的大小和通信域中的主機數(shù)目。

5.1 實驗環(huán)境

實驗所用的集群為12個節(jié)點組成的GPU同構(gòu)集群，2個MNode(為保證集群的可靠性設(shè)置一對MNode，當(dāng)其中的一個MNode出現(xiàn)故障時，另一個MNode接管主控工作)和10個CNode，MNode和CNode的功能詳見第1節(jié)，每個節(jié)點的配置信息如表2所示。

表2 實驗環(huán)境配置

說明：(1) 82579LM單向傳輸速度的峰值是1000 Mbps，雙向傳輸速度的峰值是2000 Mbps，即平常所說的千兆網(wǎng)卡的“千兆”是單向傳輸速度的峰值；(2) 圖8-圖11的橫坐標(biāo)均為單位數(shù)據(jù)包大小(Byte)，縱坐標(biāo)均為單機吞吐量(Mbps)。(3) 圖8-圖11中每個點的數(shù)據(jù)均是用如下方法得到：在相同條件下，測得多組數(shù)據(jù)，去除一個最大值，去除一個最小值，求其它數(shù)據(jù)的均值。

5.2 一對多測試/多對一測試

一對多模式，每個CNode均有一個SGP，某個SGP為發(fā)送方，其他N個SGP為接收方，發(fā)送方向每個接收方并行發(fā)送64 GB數(shù)據(jù)，實驗結(jié)果如圖8所示。多對一模式，每個CNode均有一個SGP，N個SGP為發(fā)送方，其他某個SGP為接收方，每個發(fā)送方均向接收方并行發(fā)送64 GB的數(shù)據(jù)，實驗結(jié)果如圖9所示。在這兩種通信模式下，若通信域中有n臺主機，則通信域中就有n個并發(fā)的數(shù)據(jù)流。

圖8 一對多單向通信

圖9 多對一單向通信

由圖8、圖9可以看出，隨著主機數(shù)目的增加和數(shù)據(jù)包的不斷增大，使通信域中并發(fā)的數(shù)據(jù)流增多，數(shù)據(jù)密度增大，主機的吞吐量逐漸增大直至基本不變。在“1對8”模式下，峰值穩(wěn)定吞吐量已達(dá)到835 Mbps，達(dá)到了網(wǎng)卡單向傳輸速度極限的83.5%；在“8對1”模式下，峰值穩(wěn)定吞吐量達(dá)到了網(wǎng)卡單向傳輸速度極限的82.6%。

5.3 多對多測試

多對多模式，每個CNode均有一個SGP，每個SGP既向所有其它SGP并行發(fā)送數(shù)據(jù)，同時又從所有其他SGP并行接收數(shù)據(jù)，在這種通信模式下，若通信域中有n臺主機，則通信域中就有n×(n-1)個并發(fā)的數(shù)據(jù)流，實驗結(jié)果如圖10所示。

圖10 多對多雙向通信

從圖10中可以看出，隨著系統(tǒng)中并發(fā)數(shù)據(jù)流按n的平方次冪增長和數(shù)據(jù)密度增大，吞吐量不論是同一通信域內(nèi)縱向比較還是在不同通信域內(nèi)橫向比較，都有大幅提升，特別是在數(shù)據(jù)包大小大于291字節(jié)之后。與1對1相比，4對4和8對8在圖10中選取的6個不同大小的數(shù)據(jù)包下，吞吐量分別增加了(8.4%, 16%)、(23.4%, 29.2%)、(22.7%, 34.8%)、(21%, 33%)、(21.1%, 33.5%)、(20.1%, 32.6%)，充分體現(xiàn)PDBP對并發(fā)多數(shù)據(jù)流極高的通信效率。

5.4 對比試驗：PDBP多對多與MPI全互換

MPI全互換(MPI_ALLTOALL)是MPICH標(biāo)準(zhǔn)庫函數(shù)，提供多對多通信支持[16]。由圖11可以看出，PDBP多對多與MPI全互換相比，單機吞吐量前者約是后者的9.9倍(求單位數(shù)據(jù)包相同的條件下兩者比較的各個倍數(shù)，再求這些倍數(shù)的均值)。

圖11 PDBP與MPI全互換單機吞吐量比較

5.5 PDBP提供通信支持的GPU大規(guī)模視頻流處理

實驗用的大規(guī)模數(shù)據(jù)流是10 000個QCIF(分辨率176×144)、10 000個CIF(分辨率352×288)、10 000個D1(分辨率704×576)格式的3G視頻流，每個視頻流采用H.264編碼。表3中的處理時間是指系統(tǒng)從啟動處理有節(jié)點的數(shù)據(jù)流當(dāng)前幀開始，到每個節(jié)點對的所有數(shù)據(jù)流的當(dāng)前幀處理完畢，所做的工作包括YUV圖像還原、模糊度分析和平滑度分析。

表3 H.264視頻流處理結(jié)果

從表3結(jié)果可以看出PDBP為GPU集群的大規(guī)模視頻流處理提供了高效的通信支持。

6 結(jié) 語

本文提出來一種提出了基于MPI的GPU并行通信系統(tǒng)PDBP的實現(xiàn)，適用于集群內(nèi)部大規(guī)模數(shù)據(jù)流的高效傳輸。旨在解除GPU應(yīng)用程序和MPI通信程序之間的耦合、提高通信編程效率及MPI并發(fā)多數(shù)據(jù)流的通信效率。

實驗表明，PDBP具有簡易的通信編程接口及良好的通信效率并可有效支持并發(fā)多數(shù)據(jù)流通信。未來將對動態(tài)緩沖池的調(diào)度策略和精準(zhǔn)定制PDBP的通信速度展開研究。

[1] 王海峰,陳慶奎.圖形處理器通用計算關(guān)鍵技術(shù)研究綜述[J].計算機學(xué)報,2013,36(4):757-772.

[2] Owens J D,Houston M,Luebke D,et al.GPU Computing[J].Proceedings of the IEEE,2008,96(5):879-899.

[3] Roberto Ammendola,Massimo Bernaschi.GPU peer-to-peer techniques applied to a cluster interconnect[C]//Parallel and Distributed Processing Symposium Workshops & PhD Forum,2013:806-815.

[4] 林一松,楊學(xué)軍,唐滔,等.一種基于并行度分析模型的GPU功耗優(yōu)化技術(shù)[J].計算機學(xué)報,2011,34(4):706-716.

[5] 王桂彬,楊學(xué)軍,唐滔,等.異構(gòu)并行系統(tǒng)能耗優(yōu)化分析模型[J].軟件學(xué)報,2012,23(6):1382-1396.

[6] Ali Bakhoda,George L Yuan,Wilson W L.Analyzing CUDA Workloads Using a Detailed GPU Simulator[C]//Proc of IEEE International Symposium on Performance Analysis of Systems and Software.Boston,MA:IEEE Computer Society,2009:163-174.

[7] Cheng Luo,Reiji Suda.A performance and energy consumption analytical model for GPU[C]//Proc of IEEE Ninth International Conference on Dependable,Autonomic and Secure Computing.Sydney,NSW:IEEE Computer Society,2011:658-665.

[8] Alberto Cabrera,Francisco Almeida,Vicente Blanco,et al.Analytical modeling of the energy consumption for the High Performance Linpack[C]//Proc of 21st Euromicro International Conference on Parallel,Distributed and Network-Based Processing.Belfast:IEEE Computer Society,2013:343-350.

[9] Andrea Bartolini,Matteo Cacciari.A Distributed and Self-Calibrating Model-Predictive Controller for Energy and Thermal management of High-Performance Multicores[C]//Design,Automation & Test in Europe Conference & Exhibition.Grenoble:IEEE Computer Society,2011:1-6.

[10] Sam White,Niels Verosky,Tia Newhall.A CUDA-MPI Hybrid Bitonic Sorting Algorithm for GPU Clusters[C]//Proc of the 41st International Conference on Parallel Processing Workshops,2012:354-364.

[11] Karunadasa N P,Ranasinghe D N.Accelerating high performance applications with CUDA and MPI[C]//Proc of the International Conference on Industrial and Information Systems,2009:331-336.

[12] Shane Cook.CUDA Programming:A Developer’s Guide to Parallel Computing with GPUs[M].Morgan Kaufmann Publishers Inc.,2012.

[13] NVIDIA.CUDA programming guide[M].2nd ed.NVIDIA Corporation,2008.

[14] 陳慶奎,那麗春.采用動態(tài)緩池的SOAP并行通信模型[J].北京郵電大學(xué)學(xué)報,2008,31(1):40-44.

[15] Yamagiwa S,Lisbon,Portugal L Sousa.CaravelaMPI:Message Passing Interface for Parallel GPU-Based Applications[C]//International Symposium on Parallel and Distributed Computing.Lisbon:IEEE,2009,10:161-168.

[16] 都志輝.MPI并行程序設(shè)計[M].北京:清華大學(xué)出版社,2001.

IMPLEMENTATION OF GPU CLUSTER PARALLEL COMMUNICATION SYSTEM BASED ON MPI

Hou Jingde1Chen Qingkui1,2Zhao Haiyan1

1(SchoolofOptical-ElectricalandComputerEngineering,UniversityofShanghaiforScienceandTechnology,Shanghai200093,China)2(ShanghaiKeyLaboratoryofModernOpticalSystem,Shanghai200093,China)

Given the complexity problem of GPU and MPI hybrid programming itself, we proposed a MPI-based GPU parallel communication system: the pipe dynamic buffer pool (PDBP) system. We described PDBP’s main components, architecture and implementation process, and defined the communication protocol. The system uses dynamic pipe pool and dynamic buffer pool technologies, extends the MPI parallel communication, and provides a simple and efficient communication programming interface for CUDA programmer. Experiments show that PDBP has a higher parallel communication efficiency, especially in many-to-many communication mode, the communication efficiency improves by about 9 times.

MPI Dynamic pipe pool Dynamic buffer pool Communication protocol PDBP

2014-10-30。國家自然科學(xué)基金項目(60970012)；高等學(xué)校博士學(xué)科點專項科研博導(dǎo)基金項目(20113120110008)；上海重點科技攻關(guān)項目(14511107902)；上海市工程中心建設(shè)項目(GCZX140 14)；上海市一流學(xué)科建設(shè)項目(XTKX2012)；滬江基金研究基地專項(C14001)。侯景德，碩士生，主研領(lǐng)域：并行計算。陳慶奎，教授。趙海燕，副教授。

TP3

A

10.3969/j.issn.1000-386x.2016.04.028