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

侯景德 陳慶奎,2 趙海燕

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

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

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

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

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

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

0 引 言

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

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

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

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

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

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

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

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

2 PDBP模型

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖5 實(shí)空間RS與虛空間VS

2.5 基于閾值的UMB分配算法

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

(1)

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

(2)

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

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

(3)

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

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

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

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

輸出：增加實(shí)空間后的SCBPi/RCBPi

/* 初始分配實(shí)空間 */

1. for i = 1 to n do

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

3. Allocation_RS(SCBPi/RCBPi, m)

//為子緩沖池分配實(shí)空間，大小為m

4. else 輸出提示信息

5. end if

6. end for

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

7. for i = 1 to n do

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

9. 計(jì)算SCBPi/RCBPi的SUi

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

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

12. 計(jì)算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)端主機(jī)發(fā)來消息，并將消息寫入RBP；RBP-RDT為RBP的讀線程，從RBP中讀取消息，并將消息轉(zhuǎn)發(fā)到UDAP的PriPipe中。SBP-WRT為SBP的寫線程，負(fù)責(zé)讀取PM轉(zhuǎn)發(fā)過來的發(fā)往遠(yuǎn)程主機(jī)的消息，并將消息寫入對(duì)應(yīng)的SCBP中；SBP-RDT為SBP的讀線程，主要負(fù)責(zé)從SBP中的各個(gè)SCBP中讀取消息，并將消息并行發(fā)送至遠(yuǎn)端主機(jī)。

3 通信編程接口CPI

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

進(jìn)程注冊(cè)prcsReg(…);

進(jìn)程申請(qǐng)管道prcsApplyPipe(…);

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

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

進(jìn)程釋放管道prcsReleasePipe(…);

進(jìn)程注銷prcsFree(…)。

4 消息協(xié)議MESP

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

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

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

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

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

1) 請(qǐng)求消息URMsg

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

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

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

3) 初始化消息

初始化消息主要有兩大類：主機(jī)信息消息和進(jìn)程管道綁定信息消息。

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

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

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

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

圖6 PDBP初始化時(shí)序圖

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

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

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

LocalMsg是本地?cái)?shù)據(jù)消息。

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

BPMsg是緩沖池?cái)?shù)據(jù)消息。

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

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

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

5 實(shí)驗(yàn)結(jié)果與分析

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

5.1 實(shí)驗(yàn)環(huán)境

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

表2 實(shí)驗(yàn)環(huán)境配置

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

5.2 一對(duì)多測(cè)試/多對(duì)一測(cè)試

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

圖8 一對(duì)多單向通信

圖9 多對(duì)一單向通信

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

5.3 多對(duì)多測(cè)試

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

圖10 多對(duì)多雙向通信

從圖10中可以看出，隨著系統(tǒng)中并發(fā)數(shù)據(jù)流按n的平方次冪增長和數(shù)據(jù)密度增大，吞吐量不論是同一通信域內(nèi)縱向比較還是在不同通信域內(nèi)橫向比較，都有大幅提升，特別是在數(shù)據(jù)包大小大于291字節(jié)之后。與1對(duì)1相比，4對(duì)4和8對(duì)8在圖10中選取的6個(gè)不同大小的數(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對(duì)并發(fā)多數(shù)據(jù)流極高的通信效率。

5.4 對(duì)比試驗(yàn)：PDBP多對(duì)多與MPI全互換

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

圖11 PDBP與MPI全互換單機(jī)吞吐量比較

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

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

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

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

6 結(jié) 語

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

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

[1] 王海峰,陳慶奎.圖形處理器通用計(jì)算關(guān)鍵技術(shù)研究綜述[J].計(jì)算機(jī)學(xué)報(bào),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].計(jì)算機(jī)學(xué)報(bào),2011,34(4):706-716.

[5] 王桂彬,楊學(xué)軍,唐滔,等.異構(gòu)并行系統(tǒng)能耗優(yōu)化分析模型[J].軟件學(xué)報(bào),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] 陳慶奎,那麗春.采用動(dòng)態(tài)緩池的SOAP并行通信模型[J].北京郵電大學(xué)學(xué)報(bào),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è)計(jì)[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é)基金項(xiàng)目(60970012)；高等學(xué)校博士學(xué)科點(diǎn)專項(xiàng)科研博導(dǎo)基金項(xiàng)目(20113120110008)；上海重點(diǎn)科技攻關(guān)項(xiàng)目(14511107902)；上海市工程中心建設(shè)項(xiàng)目(GCZX140 14)；上海市一流學(xué)科建設(shè)項(xiàng)目(XTKX2012)；滬江基金研究基地專項(xiàng)(C14001)。侯景德，碩士生，主研領(lǐng)域：并行計(jì)算。陳慶奎，教授。趙海燕，副教授。

TP3

A

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