侯景德 陈庆奎,2 赵海燕

基于MPI的GPU集群并行通信系统实现

侯景德1陈庆奎1,2赵海燕1

1(上海理工大学光电信息与计算机工程学院 上海 200093)

2(上海市现代光学系统重点实验室 上海 200093)

针对GPU和MPI混合编程本身的复杂性问题，提出基于MPI的GPU并行通信系统：动态管道缓冲池体系(Pipe Dynamic Buffer Pool)。描述PDBP的主要部件、体系结构和实现过程，定义通信协议。该系统采用动态管道池和动态缓冲池技术，对MPI并行通信进行扩展，为CUDA程序员提供简易高效的通信编程接口。实验表明，PDBP具有较高的并行通信效率，特别是在多对多通信模式下，通信效率提高了近9倍。

MPI 动态管道池 动态缓冲池 通信协议 PDBP

0 引 言

近年来，3D、物联网技术、移动互联网技术、4G等应用逐步展开。这些新技术的广泛应用带来了海量信息处理问题以及如何提高大规模实时支持能力的新挑战。

GPU集群具有大规模并行多核结构、多线程浮点运算的高吞吐量及使用大型片上缓存显著减少大量数据移动的时间[1-3]。GPU集群比传统CPU集群具有更好的成本效益[4-6]，不仅在速度性能上有巨大飞跃，而且显著降低空间、能源以及冷却的要求[7-10]。总之，GPU集群为应对这些新挑战带来了新的曙光。

然而，GPU集群并行编程并未出现一个标准通信模型，绝大多数集群应用采取CUDA与MPI混合编程的方法[11,12]。CUDA具有独立编译系统，无法和MPI编译系统融合[13,14]，因而开发二者混合系统为CUDA程序员带来了困难。需要了解GPU硬件架构和MPI消息传递机制，显式控制内存与显存、节点与节点间的数据传输[15]。因此，对CUDA编程人员来说，GPU集群并行编程仍是一个复杂问题。

为了解决上述问题，本文提出基于MPI的GPU集群并行通信系统PDBP的实现。该系统构建动态管道池和动态缓冲池来实现各类进程、线程之间的通信通道，定义PDBP内各个模块间交互的通信协议，以实现消息的高效传输，并且向外提供统一的通信函数接口。CUDA程序员在进行GPU和MPI混合编程时，无需了解MPI通信细节，只需调用相应通信函数，便可以进行并行GPU程序开发。使CUDA程序员从MPI编程的繁琐细节中解放出来，更加关注于上层业务算法的设计，显著改善GPU和MPI混合编程的效率。同时，由于动态缓冲池机制对MPI的扩展，极大地提高了MPI并发多数据流通信的效率。

1 GPU集群并行通信系统框架

集群通信环境CCE(Cluster Communication Environment)为四元组CCE。其中CNodes = {CNode1, CNode2, …, CNoden}是计算节点的集合，计算节点配有CPU和流处理器GPU计算资源，其支持通用C语言和流处理器程序开发环境CUDA或CTM(Close To Metal)；MNode是主控节点，负责管理CNode、集群通信初始化以及作业调度等；Net是互连网络，其上配有MPI通信环境；CS为通信软件的集合，包括MPICH、PDBP等。

广义进程为四元组GP。其中，PName为进程名；PriPipe为私有管道；RDPThread为读管道线程，WRPThread为写管道线程；CThreads = {CT1, CT2,…, CTn}是一系列计算线程的集合，一般由用户根据其业务逻辑编写。

广义进程类似于通常意义上的进程，不同之处主要是，每个GP都配备有两个管道和两个线程。一个管道用于向其他GP发送数据，另一个管道用于接收其它GP发来的数据，与两个管道相对应的有写管道线程(WRPThread)和读管道的线程(RDPThread)。按照是否与流处理器相关来划分，广义进程又被分为正常广义进程NGP(Normal Generalized Process)和流处理计算广义进程SGP(Stream Generalized Process)。流处理计算广义进程是涉及到流处理计算设备和开发环境(如CUDA、CTM)的进程，而NGP则为只涉及CPU环境运行的进程。

2 PDBP模型

管道动态缓冲池模型为五元组PDBP。其中，DPP为动态管道池，DDBP为动态双缓冲池，CPI为通信编程接口，MESP为消息协议。PDBP的总体结构如图1所示。

图1 PDBP总体结构图

2.1 动态管道池模型

这里所说的管道是一个单项流动的数据流通道，类似于UNIX操作系统中的管道。

动态管道池DPP是进程NGP之间、进程SGP之间以及进程NGP与进程SGP之间的通信的通道。它隐藏了进程NGP和SGP的差异性，对收发的消息分别进行统一封装。

动态管道池模型为五元组DPP。其中PP为管道池；GP-Tab 为广义进程表；PP={PubPipe, PriPipe}，一般PP由一个“公共管道”(PubPipe)和多个“私有管道”(PriPipe)组成。PubPipe主要是用来收集本主机中所有GP发送的数据消息的“公共信箱”，即当一个GP要向其他GP发送数据消息时，它只需启动其WRPThread向“公共信箱”写入数据消息即可，而无需参与和知晓消息发送的过程细节。PriPipe主要是本机GP接收其他GP数据消息的“私有信箱”，即当一个GP要接收来自其它GP的数据消息时，它只需启动其RDPThread从“私有信箱”读取数据消息即可，也无需参与和知晓消息接收的过程细节。

如果为每个GP都分配一个PriPipe，并且在其生命周期内一直独占此管道，显然会增大系统资源的开销和降低资源的利用率。因此GP与PriPipe采用动态绑定的方式。当一个GP需要进行与其他GP进行通信时，GP向“管道管理器”PM申请绑定一个PriPipe，PM查看“管道资源表”Pipe-Tab，将“管道池”PP中的某个处于“空闲”的管道分配给GP，并更新“管道进程绑定表” GP-Pipe-Bind-Tab；当GP通信结束后需释放其分配的PriPipe，归还到PP中。DPP结构如图2所示。

图2 DPP结构图

2.2 动态双缓冲池模型

为对MPI并行通信进行扩展以提高并发多数据流的通信效率，在通信的每台主机内都设置一个发送缓冲池和一个接受缓冲池，并且缓冲池配有线程池，以提高收发消息的高度并行性。

动态双缓冲池模型为九元组DDBP。其中SBP为发送缓冲池，RBP为接收缓冲池，UMB为用户内存块，SBPInfo-Tab为维护发送缓冲池信息的数据结构，RBPInfo-Tab为维护接收缓冲池信息的数据结构，UMBInfo-Tab为维护用户内存块信息的数据结构，HOSTInfo-Tab 为主机信息表，MainThread为主线程，负责DDBP的初始化及线程调度等，ThreadPool为对缓冲池进行读写的线程池。DDBP的结构如图3所示。

图3 DDBP结构图

2.3 发送/接收缓冲池

SBP是缓冲发往远端各个主机消息的动态环形缓冲池。其中SM为发送矩阵，SMB为SM所占用的内存块的集合。RBP是缓冲从远端各个主机接收到的消息的动态环形缓冲池。其中RM为接收矩阵，RMB为RM所占用的内存块的集合。

SM/RM都是一个M(N矩阵，其中M代表当前通信域中主机的个数，分别称SM、RM的第i行为发送子缓冲池SCBPi、接收子缓冲池RCBPi。其中0≤i≤M-1，N代表每个子缓冲池的最大容量，可以根据通信数据流的特点来调整N的大小。当前主机的SCBPi是用于向远端主机i发送数据的缓冲池，当前主机的RCBPj是用于存储从远端主机j接收到的数据的缓冲池。假设HostA、HostB为当前通信域中任意两台主机，若主机HostA要向主机HostB发送数据，则只需将HostA的SCBPB中的数据发往主机HostB，HostB将接收的数据存储在本机的RCBPA中。

2.4 用户内存块UMB

UMB是DDBP向操作系统申请的内存块的集合，每个内存块都有一个唯一的标示符blockId且大小都相同。UMB为SMB和RMB所共享，UMBInfo-Tab是维护UMB信息的数据结构。

SM和RM中的元素并不是实际存储数据的物理内存块，而是UMB中的内存块的标志blockId。因此称SM和RM的地址空间为逻辑地址空间LAS(Logical Address Space)。逻辑地址空间保证了SM和RM并行发送/接收数据时结构上的整齐性，为实现消息整列的并行发送/接收提供了结构支持。

称UMB的地址空间为物理地址空间PAS(Physical Address Space)。如果逻辑地址空间中某元素已经分配了物理地址空间中某内存块的blockId，则称此元素为“实元素”RE(Real Elements)，否则称为“虚元素”VE(Virtual Elements)。逻辑地址与物理地址的映射关系及相应的UMBInfo-Tab如图4所示。

图4 逻辑地址LAS与物理地址PAS映射关系

称逻辑地址空间中连续的RE形成的空间为实空间RS(Real Space)，称逻辑地址空间中连续的VE形成的空间为虚空间VS(Virtual Space)。称实空间与虚空间临界处的实元素为临界实元素CRE(Critical Real Elements)，称实空间与虚空间临界处的虚元素为临界虚元素CVE(Critical Virtual Elements)，如图5所示。

图5 实空间RS与虚空间VS

2.5 基于阈值的UMB分配算法

称SCBPi或RCBPi中实元素数目(‖REi‖)与元素总数目的比值，为该SCBPi或RCBPi的密度因子DFi(Density Factor)，如下式：

(1)

称SCBPi或RCBPi中已用实空间大小与当前子缓冲池实际可用实空间大小的比值，为该SCBPi或RCBPi实空间利用率SUi(Space utilization)，如下式:

(2)

其中recv、send分别为当前子缓冲池的接收、发送位置指针(下同)。

称SCBPi或RCBPi中已用实空间大小与未用实空间的比值，为该SCBPi或RCBPi收发速度比RSRi(Receive Send Ratio，简称RSR)，如下式：

(3)

阈值Threshold是基于实空间利用率SU的值，一般有0

基于阈值的UMB分配算法的基本思想：(1) 为当前通信域中的每台主机的SCBP和RCBP分配相同的实空间。(2) 对当前SCBP/RCBP，每当recv指针到达临界实元素CRE时，计算其SU。如果SU大于阈值Threshold，则说明当前SCBP/RCBP通信较为密集，那么就从位置临界虚元素CVE开始为其增加实空间。(3) 实空间的增加量根据收发速度比RSR来确定，以使每个子缓冲池的收发速率与其可用空间达到平衡，避免因接收迅速而发送迟缓造成子缓冲池“满”，导致数据溢出。

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

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

输出：增加实空间后的SCBPi/RCBPi

/* 初始分配实空间 */

1. for i = 1 to n do

2. if(UMBInfo-Tab 尚有可用内存块)

3. Allocation_RS(SCBPi/RCBPi, m)

//为子缓冲池分配实空间，大小为m

4. else 输出提示信息

5. end if

6. end for

/* 根据阈值Threshold动态调整实空间 */

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 尚有可用内存块)

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的写线程，负责接收远端主机发来消息，并将消息写入RBP；RBP-RDT为RBP的读线程，从RBP中读取消息，并将消息转发到UDAP的PriPipe中。SBP-WRT为SBP的写线程，负责读取PM转发过来的发往远程主机的消息，并将消息写入对应的SCBP中；SBP-RDT为SBP的读线程，主要负责从SBP中的各个SCBP中读取消息，并将消息并行发送至远端主机。

3 通信编程接口CPI

DDP和DDBP对GP来说是消息收发的服务者，GP若要收发消息只需调用DDP和DDBP提供的通信编程口CPI即可，主要接口有以下几个：

进程注册prcsReg(…);

进程申请管道prcsApplyPipe(…);

发送数据sendData(…);

接收数据recvData(…);

进程释放管道prcsReleasePipe(…);

进程注销prcsFree(…)。

4 消息协议MESP

在PDBP内传输的消息，主要有两类：控制消息和数据消息。控制消息主要有请求/应答消息，初始化消息和任务调度消息等，它们相对于数据消息具有实时性高、数据量小、发送和接收的进程是随机的等特点，因此PDBP消息系统也分为两部分，控制消息传输系统和数据消息传输系统。PDBP中的消息协议为MESP，其中CMP为系统中的控制消息协议集合，DMP为系统中的数据消息协议的集合。

设计消息协议MESP的基本思想：(1) 将消息分成消息头和消息体两部分。(2) 消息头尽可能短，根据PDBP各个层次的结构设计层次化的消息头。(3) 将数据统一封装在消息体中，消息体的大小通过参数可调整，以适应长消息、短消息以及数据流消息通信的不同需要。

表1 协议格式参数

4.1 控制消息协议CMP

CMP主要是为解决系统之间各个部分相互协调以及MNode管理CNode而设计的，主要有以下几种：

1) 请求消息URMsg

URMsg是GP向DPP发送的申请消息。URMsg根据type的不同可以分为GP申请注册进程的消息RegMsg和申请管道的消息APipeMsg，申请释放管道的消息ReleaseMsg以及注销进程的消息CancelMsg。

2) 应答消息DAMsg

DAMsg是DPP对GP申请消息的应答消息。DAMsg根据type的不同可以分为RegMsg的应答消息ARMsg及APipeMsg的应答消息AAPMsg。

3) 初始化消息

初始化消息主要有两大类：主机信息消息和进程管道绑定信息消息。

主机信息消息HInfoMsg，根据type的不同可以分为单机的主机信息S-HOSTInfo-Tab和当前通信域中所有主机的主机信息的集合ALL-HOSTInfo-Tab。

进程管道绑定信息消息MBInfoMsg。根据type的不同可以分为单机的进程管道绑定信息S-BInfoMsg和当前通信域中所有主机的进程管道绑定信息的集合ALL-MBInfoMsg。

4.2 利用CMP进行系统初始化

各台主机根据业务逻辑编写好各自的GP以后，就可以利用DBP和DDBP通信，但首先必须进行通信初始化，系统初始化的时序图6所示。

图6 PDBP初始化时序图

4.3 数据消息协议DMP

DMP主要是为解决系统之间各个部分收发数据消息而设计的，主要有以下几种：

UDataMsg是GP向DDP发送的数据消息。

LocalMsg是本地数据消息。

RemoteMsg是远程数据消息。

BPMsg是缓冲池数据消息。

4.4 远端消息传输

远端消息传输是指在不同主机之间传输数据消息，通常传输的数据量比较大。因此采用分层的数据包格式而非统一的数据包格式，不但最大限度地减小数据包包头的长度，而且减小了数据包解析封装的复杂性。同时提高了有效负载的传输效率，远端消息传输如图7所示。

图7 PDBP远端数据消息传输图

5 实验结果与分析

实验主要测试各个不同节点SGP与SGP之间的通信，每对进行通信的SGP之间传输数据的规模均为64 GB，64 GB的数据由多个大小相同的单位数据包组成。为测得该系统本身传输速度的极限值以及排除磁盘读写速度的限制，发送方的数据由发送方SGP生成，传输到接收方SGP后，并不进行存盘操作，只执行简单校验工作。选取的通信模式均为主机SGP与SGP之间一对多、多对一和多对多模式，并在多对多模式下将PDBP与传统MPI全互换的吞吐量进行对比。每种通信模式下选取的自变量主要是单位数据包的大小和通信域中的主机数目。

5.1 实验环境

实验所用的集群为12个节点组成的GPU同构集群，2个MNode(为保证集群的可靠性设置一对MNode，当其中的一个MNode出现故障时，另一个MNode接管主控工作)和10个CNode，MNode和CNode的功能详见第1节，每个节点的配置信息如表2所示。

表2 实验环境配置

说明：(1) 82579LM单向传输速度的峰值是1000 Mbps，双向传输速度的峰值是2000 Mbps，即平常所说的千兆网卡的“千兆”是单向传输速度的峰值；(2) 图8-图11的横坐标均为单位数据包大小(Byte)，纵坐标均为单机吞吐量(Mbps)。(3) 图8-图11中每个点的数据均是用如下方法得到：在相同条件下，测得多组数据，去除一个最大值，去除一个最小值，求其它数据的均值。

5.2 一对多测试/多对一测试

一对多模式，每个CNode均有一个SGP，某个SGP为发送方，其他N个SGP为接收方，发送方向每个接收方并行发送64 GB数据，实验结果如图8所示。多对一模式，每个CNode均有一个SGP，N个SGP为发送方，其他某个SGP为接收方，每个发送方均向接收方并行发送64 GB的数据，实验结果如图9所示。在这两种通信模式下，若通信域中有n台主机，则通信域中就有n个并发的数据流。

图8 一对多单向通信

图9 多对一单向通信

由图8、图9可以看出，随着主机数目的增加和数据包的不断增大，使通信域中并发的数据流增多，数据密度增大，主机的吞吐量逐渐增大直至基本不变。在“1对8”模式下，峰值稳定吞吐量已达到835 Mbps，达到了网卡单向传输速度极限的83.5%；在“8对1”模式下，峰值稳定吞吐量达到了网卡单向传输速度极限的82.6%。

5.3 多对多测试

多对多模式，每个CNode均有一个SGP，每个SGP既向所有其它SGP并行发送数据，同时又从所有其他SGP并行接收数据，在这种通信模式下，若通信域中有n台主机，则通信域中就有n×(n-1)个并发的数据流，实验结果如图10所示。

图10 多对多双向通信

从图10中可以看出，随着系统中并发数据流按n的平方次幂增长和数据密度增大，吞吐量不论是同一通信域内纵向比较还是在不同通信域内横向比较，都有大幅提升，特别是在数据包大小大于291字节之后。与1对1相比，4对4和8对8在图10中选取的6个不同大小的数据包下，吞吐量分别增加了(8.4%, 16%)、(23.4%, 29.2%)、(22.7%, 34.8%)、(21%, 33%)、(21.1%, 33.5%)、(20.1%, 32.6%)，充分体现PDBP对并发多数据流极高的通信效率。

5.4 对比试验：PDBP多对多与MPI全互换

MPI全互换(MPI_ALLTOALL)是MPICH标准库函数，提供多对多通信支持[16]。由图11可以看出，PDBP多对多与MPI全互换相比，单机吞吐量前者约是后者的9.9倍(求单位数据包相同的条件下两者比较的各个倍数，再求这些倍数的均值)。

图11 PDBP与MPI全互换单机吞吐量比较

5.5 PDBP提供通信支持的GPU大规模视频流处理

实验用的大规模数据流是10 000个QCIF(分辨率176×144)、10 000个CIF(分辨率352×288)、10 000个D1(分辨率704×576)格式的3G视频流，每个视频流采用H.264编码。表3中的处理时间是指系统从启动处理有节点的数据流当前帧开始，到每个节点对的所有数据流的当前帧处理完毕，所做的工作包括YUV图像还原、模糊度分析和平滑度分析。

表3 H.264视频流处理结果

从表3结果可以看出PDBP为GPU集群的大规模视频流处理提供了高效的通信支持。

6 结 语

本文提出来一种提出了基于MPI的GPU并行通信系统PDBP的实现，适用于集群内部大规模数据流的高效传输。旨在解除GPU应用程序和MPI通信程序之间的耦合、提高通信编程效率及MPI并发多数据流的通信效率。

实验表明，PDBP具有简易的通信编程接口及良好的通信效率并可有效支持并发多数据流通信。未来将对动态缓冲池的调度策略和精准定制PDBP的通信速度展开研究。

[1] 王海峰,陈庆奎.图形处理器通用计算关键技术研究综述[J].计算机学报,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] 林一松,杨学军,唐滔,等.一种基于并行度分析模型的GPU功耗优化技术[J].计算机学报,2011,34(4):706-716.

[5] 王桂彬,杨学军,唐滔,等.异构并行系统能耗优化分析模型[J].软件学报,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] 陈庆奎,那丽春.采用动态缓池的SOAP并行通信模型[J].北京邮电大学学报,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并行程序设计[M].北京:清华大学出版社,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。国家自然科学基金项目(60970012)；高等学校博士学科点专项科研博导基金项目(20113120110008)；上海重点科技攻关项目(14511107902)；上海市工程中心建设项目(GCZX140 14)；上海市一流学科建设项目(XTKX2012)；沪江基金研究基地专项(C14001)。侯景德，硕士生，主研领域：并行计算。陈庆奎，教授。赵海燕，副教授。

TP3

A

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