徐 恒 吳俊敏 楊志剛 尹 燕

1(中國科學(xué)技術(shù)大學(xué)軟件學(xué)院 安徽 合肥 230027) 2(中國科學(xué)技術(shù)大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院 安徽 合肥 230027) 3(中國科學(xué)技術(shù)大學(xué)蘇州研究院 江蘇 蘇州 215123)

基于虛擬化環(huán)境的多GPU并行通用計(jì)算平臺(tái)研究

徐 恒1,3吳俊敏2,3楊志剛2尹 燕2

1(中國科學(xué)技術(shù)大學(xué)軟件學(xué)院 安徽 合肥 230027)2(中國科學(xué)技術(shù)大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院 安徽 合肥 230027)3(中國科學(xué)技術(shù)大學(xué)蘇州研究院 江蘇 蘇州 215123)

針對(duì)分布式多節(jié)點(diǎn)多GPU的系統(tǒng)環(huán)境，實(shí)現(xiàn)一種基于CUDA框架的多GPU通用計(jì)算虛擬化平臺(tái)。應(yīng)用程序可以如同使用本地GPU一樣方便地使用多個(gè)遠(yuǎn)程GPU，原來的CUDA應(yīng)用程序可以不經(jīng)過修改或者只進(jìn)行少量的修改就可以運(yùn)行在該虛擬化GPU平臺(tái)上，從而實(shí)現(xiàn)單機(jī)多GPU和多機(jī)多GPU在編程模式上的統(tǒng)一，并通過一個(gè)基于高斯混合模型的數(shù)據(jù)聚類程序來進(jìn)行實(shí)驗(yàn)驗(yàn)證。實(shí)驗(yàn)結(jié)果表明，在不影響程序正確性的前提下，相對(duì)于原來使用CPU的程序，使用兩個(gè)遠(yuǎn)程GPU可以獲得十倍左右的加速比。

虛擬化 GPU 多機(jī)多GPU 分布式

0 引 言

近年來， GPU的通用計(jì)算功能得到了迅速發(fā)展。隨著GPU的性能提高以及GPU自身的結(jié)構(gòu)特性，使得GPU在大規(guī)模并行計(jì)算中起著越來越重要的作用，對(duì)于GPU的通用計(jì)算功能的研究也成為了熱點(diǎn)。在通用計(jì)算領(lǐng)域，以CUDA為代表的并行計(jì)算架構(gòu)將GPU引入到科學(xué)計(jì)算。但是CUDA規(guī)范只能直接訪問本地的GPU，并沒有直接提供對(duì)遠(yuǎn)程GPU的訪問接口，為了能夠使用網(wǎng)絡(luò)中的遠(yuǎn)程GPU，開發(fā)人員需要用到MPI與CUDA結(jié)合等方法，這增加了程序的復(fù)雜性并且給開發(fā)人員帶來額外的工作量。

為了能夠更加方便地使用多GPU系統(tǒng)的計(jì)算資源，本文以開源項(xiàng)目gVirtuS為基礎(chǔ)，實(shí)現(xiàn)了一種基于CUDA框架的、支持多GPU通用計(jì)算的虛擬化方案，可以將分布式環(huán)境中多個(gè)節(jié)點(diǎn)的GPU資源的統(tǒng)一抽象到一個(gè)GPU池中。程序可以用本地GPU的方式使用任意位置、任意數(shù)量的GPU的資源，原有的CUDA程序可以不修改源代碼只要在編譯過程中進(jìn)行簡單的配置就可以在該虛擬化平臺(tái)上運(yùn)行，即使沒有GPU設(shè)備或者只有不支持CUDA的GPU設(shè)備也能夠十分方便地使用分布式環(huán)境中的非本地GPU資源進(jìn)行通用計(jì)算。

1 GPU虛擬化背景

虛擬化技術(shù)在現(xiàn)代計(jì)算機(jī)系統(tǒng)中有非常廣泛的應(yīng)用，是對(duì)傳統(tǒng)計(jì)算資源的使用方式的一種突破。在虛擬化技術(shù)中，由于I/O設(shè)備的復(fù)雜性、多樣性與封閉性，針對(duì)I/O設(shè)備的虛擬化一直是瓶頸。GPU屬于I/O設(shè)備中的特殊部分，其功能主要有圖形計(jì)算與通用計(jì)算兩部分，近年來隨著神經(jīng)網(wǎng)絡(luò)的興起，GPU的通用計(jì)算功能越來越受重視，針對(duì)GPU通用計(jì)算的虛擬化一直是學(xué)術(shù)界研究的熱點(diǎn)。目前GPU虛擬化技術(shù)主要有三類：1) 設(shè)備獨(dú)占;2) 設(shè)備模擬；3) 應(yīng)用層接口虛擬化(即API重定向)。此外還有硬件虛擬化，但是運(yùn)用較少。

由于CUDA的廣泛應(yīng)用，對(duì)GPU通用計(jì)算的虛擬化主要是基于CUDA的解決方案，例如rCUDA[1]、vCUDA[2-3]、 gVirtuS[4]、Gvim[5]等。其中vCUDA是針對(duì)在虛擬機(jī)環(huán)境中運(yùn)行CUDA程序提出的解決方案，“采用在用戶層攔截和重定向CUDA API的方法，在虛擬機(jī)中建立物理GPU的邏輯映像”[3]。vCUDA出現(xiàn)時(shí)間較早，對(duì)于CUDA 4.0之后的版本不再支持。Gvim是基于Xen系統(tǒng)的，實(shí)現(xiàn)了基于前后端的CUDA虛擬化系統(tǒng)，但是并沒有實(shí)現(xiàn)CUDA全部功能的虛擬化。rCUDA是目前比較成熟的GPU虛擬化解決方案，支持最新的CUDA 7.5，支持cuDNN，其不再側(cè)重于針對(duì)虛擬機(jī)的GPU虛擬化，而是所有不包括NVIDIA GPU的節(jié)點(diǎn)都可以使用rCUDA來使用GPU進(jìn)行通用計(jì)算。rCUDA可以免費(fèi)獲得，但是不開源，其具體實(shí)現(xiàn)細(xì)節(jié)與原理都未公開。gVirtuS是基于前后端模式實(shí)現(xiàn)的GPU通用計(jì)算虛擬化方案，其前端提供了一個(gè)封裝了CUDA接口的偽庫。在前端的所有的對(duì)CUDA API的調(diào)用都會(huì)被這個(gè)偽庫攔截并轉(zhuǎn)發(fā)到后端進(jìn)行處理，而后端則運(yùn)行在具有處理能力的宿主機(jī)上，負(fù)責(zé)處理前端發(fā)來的請(qǐng)求。這種虛擬化方案被稱為API重定向( API remoting)，其訪問遠(yuǎn)程GPU時(shí)采用的前后端通信方式是TCP/IP，只能使用一臺(tái)遠(yuǎn)程主機(jī)中的GPU資源。

以上方案無論是針對(duì)虛擬機(jī)的vCUDA還是針對(duì)遠(yuǎn)程物理機(jī)的rCUDA，其設(shè)計(jì)都包含有高效性、普適性、透明性三個(gè)原則。高效性是要求虛擬化方案不能帶來額外的開銷；普適性是指虛擬化方案不能只針對(duì)特定虛擬化平臺(tái)有效，在本文中的虛擬化方案除了虛擬化平臺(tái)外還包括了沒有GPU的物理平臺(tái)；透明性是指虛擬化的方案對(duì)于CUDA應(yīng)用保證兼容性，不要求修改CUDA程序源碼或者重新編譯，或者只需要做很少的修改就可以在虛擬化平臺(tái)上運(yùn)行，在透明性良好的虛擬化方案中，原有的單機(jī)多GPU程序可以直接在多機(jī)多GPU的分布式環(huán)境中運(yùn)行，從而實(shí)現(xiàn)了不同環(huán)境中的編程模式的統(tǒng)一，這也是本文研究的重點(diǎn)。

2 單GPU虛擬化

本節(jié)討論如何通過API重定向虛擬化方案來訪問單個(gè)的遠(yuǎn)程GPU進(jìn)行通用計(jì)算的問題，以此為基礎(chǔ)，下一節(jié)再來討論如何使用分布式環(huán)境中的多個(gè)GPU的問題。在本文中的“虛擬節(jié)點(diǎn)”這個(gè)術(shù)語有兩層含義：一是指傳統(tǒng)意義上的虛擬機(jī)節(jié)點(diǎn)；二是指沒有配備可以運(yùn)行CUDA的GPU的物理機(jī)節(jié)點(diǎn)。為了不引起歧義，本文使用“前端節(jié)點(diǎn)”這個(gè)術(shù)語來指代以上兩層含義。相應(yīng)的，使用“后端節(jié)點(diǎn)”這個(gè)術(shù)語來指代宿主機(jī)。

2.1 API重定向虛擬化方案

API重定向技術(shù)虛擬化方案[6]，是一種應(yīng)用層接口虛擬化，是對(duì)GPU相關(guān)的應(yīng)用程序編程接口在應(yīng)用層進(jìn)行攔截，然后使用重定向方式實(shí)現(xiàn)相應(yīng)的功能，將完成的結(jié)果返回給對(duì)應(yīng)的應(yīng)用程序。

這種方案是針對(duì)CUDA運(yùn)行時(shí)API(Runtime API)進(jìn)行虛擬化，為前端提供了一個(gè)運(yùn)行時(shí)偽庫，該偽庫重寫了CUDA的運(yùn)行時(shí)API，將其實(shí)現(xiàn)為對(duì)后端的遠(yuǎn)程調(diào)用。前端編寫的CUDA程序?qū)UDA API的調(diào)用被偽庫動(dòng)態(tài)攔截，偽庫將CUDA API的參數(shù)與名稱發(fā)送到前端通信部分，再由前端通信部分通過網(wǎng)絡(luò)發(fā)送給后端，后端接受相應(yīng)參數(shù)后調(diào)用真正的CUDA程序進(jìn)行計(jì)算，然后將運(yùn)行結(jié)果返回給前端。結(jié)構(gòu)如圖1所示。

圖1 API重定向虛擬化方案結(jié)構(gòu)

這種方案解耦了上層軟件與底層硬件之間的強(qiáng)耦合關(guān)系，不僅可以應(yīng)用在虛擬機(jī)中，也可以為沒有配備GPU資源或者配備了缺少支持CUDA的GPU資源的計(jì)算機(jī)提供一種使用遠(yuǎn)程節(jié)點(diǎn)上的GPU的方法。這兩種方案的區(qū)別在于前端與后端的通信方式的不同：在虛擬機(jī)中可以利用虛擬機(jī)與宿主機(jī)之間的高速通信方式，而在訪問遠(yuǎn)程節(jié)點(diǎn)上的GPU時(shí)只能使用網(wǎng)絡(luò)通信。

這種方案不依賴于特定的虛擬化平臺(tái)，前端節(jié)點(diǎn)可以是一個(gè)Xen、KVM、Vmware或者其他任何一臺(tái)虛擬機(jī)，甚至可以是一臺(tái)真正的物理機(jī)，只要與后端節(jié)點(diǎn)有網(wǎng)絡(luò)連通，都可以使用這種方案來搭建虛擬化平臺(tái)。搭建的方式也十分簡單，只需要在前端節(jié)點(diǎn)中安裝好運(yùn)行時(shí)偽庫(一般與原裝庫同名)，然后在配置文件中將后端節(jié)點(diǎn)的IP地址正確的寫入即可。原本的代碼不需要做任何的修改，只要在編譯時(shí)將偽庫鏈接到可執(zhí)行文件中，源程序不需要做任何的修改就可以運(yùn)行在虛擬化平臺(tái)上。應(yīng)用程序可以如同使用本地GPU一樣方便地使用遠(yuǎn)程GPU，虛擬化平臺(tái)的復(fù)雜的執(zhí)行流程對(duì)程序員完全透明。

一個(gè)典型的CDUA API的執(zhí)行過程如圖2所示，不同的API執(zhí)行步驟會(huì)有差異，但基本流程都是如圖2所示。圖中虛框部分是虛擬化平臺(tái)所做的處理，一般包括前端部分與后端部分，分別位于不同的節(jié)點(diǎn)上。前端節(jié)點(diǎn)與后端節(jié)點(diǎn)之間的交互包括數(shù)據(jù)傳輸與函數(shù)調(diào)用，前端的所有參數(shù)都會(huì)被偽庫攔截轉(zhuǎn)發(fā)給后端，后端節(jié)點(diǎn)接收了參數(shù)之后會(huì)啟動(dòng)核函數(shù)進(jìn)行運(yùn)算，最后將結(jié)果返回給前端節(jié)點(diǎn)。每一個(gè)CUDA API在執(zhí)行時(shí)都會(huì)涉及上述步驟，執(zhí)行期間會(huì)有大量數(shù)據(jù)傳輸，涉及不同組件、不同節(jié)點(diǎn)，數(shù)據(jù)傳輸對(duì)應(yīng)用程序的性能會(huì)產(chǎn)生重大影響，是虛擬化方案設(shè)計(jì)時(shí)要解決的重要問題。

圖2 CUDA函數(shù)在虛擬化平臺(tái)上的執(zhí)行流程

2.2 程序在虛擬化平臺(tái)上的執(zhí)行過程

圖2顯示了CUDA函數(shù)在虛擬化平臺(tái)上的執(zhí)行流程，與直接在本地上運(yùn)行時(shí)不同，在虛擬化平臺(tái)上程序執(zhí)行時(shí)被分解為了前端與后端兩個(gè)部分，這使得其執(zhí)行步驟更加復(fù)雜。在沒有虛擬化的環(huán)境下，一次GPU運(yùn)算的過程可以簡單地分成三個(gè)步驟：

1) 將數(shù)據(jù)從主機(jī)內(nèi)存拷貝到GPU顯存。

2) 在GPU上啟動(dòng)核函數(shù)，開始計(jì)算。

3) 將結(jié)果由GPU顯存拷貝回主機(jī)內(nèi)存。

在虛擬化方案中，由于前端節(jié)點(diǎn)與后端節(jié)點(diǎn)往往不是在一臺(tái)機(jī)器上，除了必要的數(shù)據(jù)外，前后端之間還需要傳輸大量的參數(shù)信息與控制信息，這些都是由虛擬化平臺(tái)來處理。

圖3是一個(gè)求后端節(jié)點(diǎn)的GPU數(shù)目的簡單程序，原程序不需要做任何的修改就可以移植到虛擬化平臺(tái)上，并得到正確的結(jié)果，只是其執(zhí)行的流程更加復(fù)雜：

1) 根據(jù)配置文件中提供的IP地址，前端傳輸相關(guān)的參數(shù)到后端，完成GPU資源的初始化，并傳回句柄的相關(guān)信息。如果無法完成初始化，則報(bào)錯(cuò)。

2) 在后端GPU上注冊(cè)代碼段(FatBinary)，程序在本地上運(yùn)行時(shí)，這一步驟會(huì)隱式的調(diào)用一個(gè)CUDA未公開的API _cudaRegisterFatBinary()來完成如內(nèi)存偏移、空間大小、GPU設(shè)備編號(hào)等相關(guān)初始化工作。該API是在程序的所有代碼之前被調(diào)用。在虛擬化環(huán)境下，這一過程由平臺(tái)來完成，同樣對(duì)前端編程人員透明。

3) 將計(jì)算數(shù)據(jù)與參數(shù)從前端內(nèi)存?zhèn)鬏數(shù)胶蠖斯?jié)點(diǎn)的內(nèi)存，這往往是通往網(wǎng)絡(luò)傳輸?shù)摹?/p>

4) 根據(jù)前端傳輸過來的參數(shù)以及控制信息，后端節(jié)點(diǎn)調(diào)用GPU進(jìn)行計(jì)算。

5) 后端節(jié)點(diǎn)將計(jì)算結(jié)果拷貝回主存，釋放資源，并且完成相關(guān)的清理工作，在GPU程序的所有代碼執(zhí)行結(jié)束之后，還需要調(diào)用另外一個(gè)未公開的CUDA API： _cudaUnregisterFatBinary()來注銷相關(guān)的信息。

6) 虛擬化平臺(tái)的后端將計(jì)算結(jié)果傳回給前端節(jié)點(diǎn)。

圖3 一個(gè)簡單程序在虛擬化平臺(tái)上的執(zhí)行

上述一個(gè)簡單的求后端節(jié)點(diǎn)的GPU數(shù)目的例子中就涉及到了兩個(gè)未公開的CUDA API。由于CUDA的封閉性，還有其余未曾公開的API，這些不曾出現(xiàn)在官方文檔中的API是實(shí)現(xiàn)虛擬化方案的過程中需要處理的棘手問題。為了保證虛擬化平臺(tái)的透明性，這些API的功能都是由虛擬化平臺(tái)來實(shí)現(xiàn)。

以上是對(duì)虛擬化平臺(tái)的程序執(zhí)行步驟的簡單介紹。一個(gè)簡單的程序在虛擬化平臺(tái)上的運(yùn)行過程往往就涉及到了復(fù)雜的參數(shù)傳遞與控制信息傳遞，這些數(shù)據(jù)都要通過網(wǎng)絡(luò)來傳輸，新增加的軟件棧也會(huì)導(dǎo)致性能降低。另外，在一些程序中，需要處理大量的數(shù)據(jù)，這些數(shù)據(jù)在前端/后端之間傳輸所帶來的延時(shí)往往會(huì)比GPU處理這些數(shù)據(jù)的時(shí)間高的多，這也常常成為程序的性能瓶頸。

2.3 改變通信方式提高效率

在2.1小節(jié)論述了論述了虛擬化平臺(tái)的普適性、透明性原則，本小節(jié)討論虛擬化過程的效率性。本文采用的API重定向技術(shù)是在應(yīng)用層完成了對(duì)GPU的虛擬化，這是一種在CUDA的封閉、不了解其內(nèi)部細(xì)節(jié)情況下提出的虛擬化方案[7]，也是目前研究GPU通用計(jì)算虛擬化的主流方案。API重定向方案可以解決CUDA封閉性問題，然而由于需要攔截/轉(zhuǎn)發(fā)、前端處理、后端處理等步驟來實(shí)現(xiàn)平臺(tái)的功能并對(duì)上層程序員透明，因此帶來了額外傳輸開銷與控制開銷。新增加的軟件棧也會(huì)降低系統(tǒng)的性能[8]，尤其是在采用網(wǎng)絡(luò)傳輸來實(shí)現(xiàn)前端/后端的參數(shù)傳遞與數(shù)據(jù)傳輸時(shí)。相對(duì)于主機(jī)內(nèi)存到GPU顯存的高速傳輸，網(wǎng)絡(luò)傳輸?shù)难訒r(shí)往往會(huì)高好幾個(gè)數(shù)量級(jí)，這部分開銷也成了整體性能的瓶頸，如何通過提高通信的性能也是本文要討論的重點(diǎn)。

前端節(jié)點(diǎn)與后端節(jié)點(diǎn)的通信方式有不同的選擇，當(dāng)需要訪問遠(yuǎn)程的GPU時(shí)，采用的是基于socket的傳輸方式進(jìn)行通信，這帶來兩個(gè)問題，一是前端/后端之間的數(shù)據(jù)傳輸延時(shí)比較大；二是一個(gè)前端節(jié)點(diǎn)只能與一個(gè)后端節(jié)點(diǎn)進(jìn)行通信，無法同時(shí)對(duì)多個(gè)GPU進(jìn)行抽象和映射。本小節(jié)將其通信方式改為ZeroMQ來解決第一個(gè)問題，第二個(gè)問題在第4節(jié)討論。由第2.1小節(jié)可以知道，通信部分為CUDA編程提供了有效的底層通信接口，前端通信部分與后端通信部分的關(guān)聯(lián)十分緊密，而通信部分與系統(tǒng)的其余部分的耦合性并不高，在深入研究之后為系統(tǒng)增加了一種新的高效通信方式：ZeroMQ通信方式。

ZeroMQ是一種基于消息隊(duì)列的多線程網(wǎng)絡(luò)庫，其對(duì)套接字類型的底層細(xì)節(jié)進(jìn)行抽象，提供跨越多種傳輸協(xié)議的套接字。相對(duì)于Socket來說ZeroMQ是一個(gè)更為高效的傳輸層協(xié)議。ZeroMQ設(shè)計(jì)之初就是為了高性能的消息發(fā)送而服務(wù)的，所以其設(shè)計(jì)追求簡潔高效。ZeroMQ是面向“消息”的而非字節(jié)流，發(fā)送消息采用異步模式。

實(shí)驗(yàn)表明，采用ZeroMQ通信方式的程序能夠比原來的Socket方式整體性能更高。實(shí)驗(yàn)中的后端節(jié)點(diǎn)配置Inter(R) Core(TM) i5-4590CPU(3.3 GHz)處理器，4 GB內(nèi)存和100 GB硬盤，GeForce GTX750 Ti GPU，Ubuntu 14.04 64位操作系統(tǒng)，CUDA版本為7.5。前端節(jié)點(diǎn)是一臺(tái)物理機(jī)，配置Celeron(R) Dual-Core CPU T3000(1.8 GHz)處理器，3 GB內(nèi)存和30 GB硬盤，沒有NVIDIA顯卡，也沒有安裝CUDA程序，Ubuntu 14.04 64位操作系統(tǒng)。前后端之間通過百兆以太網(wǎng)交換機(jī)互聯(lián)。由于網(wǎng)絡(luò)環(huán)境會(huì)影響到實(shí)驗(yàn)結(jié)果，所以每組數(shù)據(jù)都是測(cè)試多次取平均值，實(shí)驗(yàn)運(yùn)行的程序都是CUDA SDK自帶的程序。計(jì)算性能實(shí)驗(yàn)在三類平臺(tái)上進(jìn)行對(duì)比，即本地GPU計(jì)算平臺(tái)、基于Socket通信方式的虛擬化計(jì)算平臺(tái)以及基于ZeroMQ通信方式的虛擬化計(jì)算平臺(tái)。

圖4顯示的是向量加法的性能實(shí)驗(yàn)結(jié)果，其中橫坐標(biāo)表示的是向量長度，縱坐標(biāo)是運(yùn)行時(shí)間。除了運(yùn)行時(shí)間不同之外，運(yùn)行結(jié)果與本地機(jī)上的運(yùn)行結(jié)果沒有差別，說明虛擬化平臺(tái)不會(huì)對(duì)程序的正確性有影響。實(shí)驗(yàn)結(jié)果表明使用ZeroMQ通信方式可以提高系統(tǒng)的整體性能，在這個(gè)程序中，可以獲得20%～35%的性能加速。然而與本地運(yùn)行的程序相比，隨著數(shù)據(jù)量的加大，不論是哪一種通信方式的虛擬化方案所帶來的性能損失也越來越大。這是因?yàn)殡S著向量規(guī)模的增加需要傳輸?shù)臄?shù)據(jù)量越多，就有更多的數(shù)據(jù)和參數(shù)需要在前端/后端之間傳遞，自然會(huì)有更大的傳輸開銷與控制開銷。而數(shù)據(jù)在GPU上計(jì)算所增加的時(shí)間并不多，這是因?yàn)镚PU特別適合處理向量加法這種可以并行的程序，因此數(shù)據(jù)規(guī)模的加大并不會(huì)使GPU的運(yùn)算時(shí)間大幅提高。

圖4 不同平臺(tái)上向量加法程序的執(zhí)行結(jié)果

在GPU上運(yùn)行的往往不會(huì)是向量加法這么方便地進(jìn)行并行處理的程序，比如復(fù)雜一些的CUDA程序：矩陣乘法，這是一個(gè)計(jì)算密集型程序，其需要傳輸?shù)臄?shù)據(jù)并不太多，而GPU的運(yùn)算卻相對(duì)復(fù)雜，結(jié)果如圖5所示。

圖5 不同平臺(tái)上矩陣乘法程序的執(zhí)行結(jié)果

圖5中橫坐標(biāo)是參加運(yùn)算的矩陣的階數(shù)，縱坐標(biāo)是程序的運(yùn)行時(shí)間。實(shí)驗(yàn)結(jié)果表明，當(dāng)矩陣規(guī)模越大時(shí)，虛擬化方案的性能反而越接近物理機(jī)，當(dāng)矩陣的規(guī)模為960×960時(shí)，程序在基于ZeroMQ的虛擬化平臺(tái)上的運(yùn)行時(shí)間是在物理機(jī)器上運(yùn)行時(shí)間的1.12倍，此時(shí)達(dá)到臨界點(diǎn)，規(guī)模更大的矩陣運(yùn)算不會(huì)使程序的性能更接近本地機(jī)，因?yàn)閭鬏旈_銷與控制開銷以及額外的軟件棧等是虛擬化無法避免的性能損失。以上實(shí)驗(yàn)結(jié)果表明虛擬化平臺(tái)在處理計(jì)算密集型的程序時(shí)損失的性能會(huì)相對(duì)較少。圖5中還顯示了另外一個(gè)問題：基于ZeroMQ方式與基于Socket方式的虛擬化平臺(tái)之間的性能差距不再十分明顯。這同樣是由于程序的計(jì)算比較復(fù)雜，需要GPU運(yùn)算的時(shí)間大大超過了數(shù)據(jù)在網(wǎng)絡(luò)中傳輸?shù)臅r(shí)間，通過改變通信方式獲得的性能提升不再明顯，那么為什么依舊選擇ZeroMQ呢？下一節(jié)的多GPU虛擬化來討論這個(gè)問題。

3 多GPU虛擬化

多GPU平臺(tái)主要有兩種構(gòu)架，如圖6所示。一種是單機(jī)多GPU，另一種是多機(jī)多GPU，即GPU集群[9]。在編程方式上，在單機(jī)多GPU的環(huán)境下CUDA提供了直接的編程接口，而對(duì)于多機(jī)多GPU的結(jié)構(gòu)CUDA沒有相關(guān)的編程接口，需要借助其他工具，如基于MPI與CUDA相結(jié)合的方式，要求編程人員顯式地采用分布式MPI編程。目前的多GPU的處理方案中，一般都是將兩種情況區(qū)別對(duì)待，運(yùn)行在單機(jī)多GPU上的CUDA代碼需要進(jìn)行很大的修改才能移植到多機(jī)多GPU的環(huán)境上，如何實(shí)現(xiàn)二者在編程模式上的統(tǒng)一是本文討論的重點(diǎn)。

圖6 單機(jī)多GPU與多機(jī)多GPU

在第2節(jié)中提到的基于Socket方式來實(shí)現(xiàn)的單GPU虛擬化方案中，由于Socket只支持一對(duì)一的通信，一個(gè)前端節(jié)點(diǎn)只能訪問一個(gè)遠(yuǎn)程GPU，無法同時(shí)調(diào)用集群環(huán)境中的多個(gè)GPU來加速應(yīng)用程序。因此，在基于ZeroMQ通信方式的虛擬化方案除了能夠提高效率外，還實(shí)現(xiàn)了另外的功能：ZeroMQ支持一對(duì)多的通信，從而能夠同時(shí)使用多個(gè)遠(yuǎn)程GPU，實(shí)現(xiàn)多GPU的虛擬化方案，如圖7所示。一個(gè)前端節(jié)點(diǎn)可以綁定多個(gè)后端節(jié)點(diǎn)的IP地址，從而能夠通過ZeroMQ同時(shí)調(diào)用多個(gè)后端節(jié)點(diǎn)上的GPU資源。GPU集群中存在多個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)配備了不同的GPU資源，節(jié)點(diǎn)之間通過網(wǎng)絡(luò)互連。在虛擬化的過程中，通過IP地址來標(biāo)識(shí)不同節(jié)點(diǎn)的GPU，將其映射到一個(gè)統(tǒng)一的GPU池中，并且順序編號(hào)為GPU0，GPU1，…，GPUn等。所有分布式環(huán)境下需要解決的容錯(cuò)性，冗余性等問題都在虛擬化過程中解決。對(duì)于前端節(jié)點(diǎn)來說，其能夠使用的GPU的最大數(shù)目就是這個(gè)GPU池中的數(shù)目。在邏輯上，前端應(yīng)用調(diào)用這個(gè)GPU池中的GPU的方式和使用本地GPU的方式完全相同，從而將多機(jī)多GPU卡的物理環(huán)境抽象成了單機(jī)多GPU卡的邏輯環(huán)境，使得單機(jī)多卡的程序可以不用修改或者只做很少的修改就可以運(yùn)行在多機(jī)多卡的環(huán)境下，實(shí)現(xiàn)了兩個(gè)環(huán)境編程模式的統(tǒng)一。

圖7 多GPU虛擬化平臺(tái)的物理結(jié)構(gòu)與邏輯結(jié)構(gòu)

如圖7所示，集群中的所有GPU資源都由虛擬化平臺(tái)來管理，前端需要使用GPU資源時(shí)，只需要在配置文件中準(zhǔn)確描述后端節(jié)點(diǎn)的IP地址和需要的GPU數(shù)目，就可以將相應(yīng)節(jié)點(diǎn)上的GPU映射到本地。應(yīng)用程序可以像訪問本地GPU一樣調(diào)用這些映射來的GPU進(jìn)行加速。此外當(dāng)有些程序需要的GPU資源超過了單個(gè)節(jié)點(diǎn)的能力時(shí)，這也是一種很好的解決方案。程序開發(fā)過程中，開發(fā)人員只需要專注于CUDA編程， GPU資源的分布、數(shù)據(jù)的傳輸、冗余與錯(cuò)誤處理等都交給虛擬化平臺(tái)來處理。這種方式的靈活性極好，對(duì)GPU資源的分配只需要修改配置文件即可。

多GPU虛擬化平臺(tái)的優(yōu)勢(shì)是可以使用分布式環(huán)境中的其他節(jié)點(diǎn)的GPU資源，并且理論上沒有數(shù)目的限制，具體需要使用多少的GPU資源取決于程序開發(fā)人員和分布式環(huán)境中的GPU資源數(shù)目。此外由于虛擬化平臺(tái)的透明性很好，使用遠(yuǎn)程GPU的方式就如同使用本地GPU一樣，可以直接通過CUDA提供的接口方便的調(diào)用，可移植性非常好。例如CUDA SDK自帶的多GPU samples程序絕大部分都可以直接運(yùn)行在虛擬化平臺(tái)上，不需要修改源碼，只需要修改編譯時(shí)的選項(xiàng)并重新編譯即可，只不過這些程序往往都是以演示功能為主，計(jì)算規(guī)模不大，并不能體現(xiàn)出多GPU虛擬化的優(yōu)勢(shì)。

在第2節(jié)中詳細(xì)分析了程序在單GPU的虛擬化平臺(tái)上的執(zhí)行流程，在多GPU的虛擬化環(huán)境下程序的執(zhí)行流程也是基本如此。此外在進(jìn)行多GPU的并行計(jì)算時(shí)，還有數(shù)據(jù)的分解、運(yùn)算和合并等步驟，因此會(huì)帶來更多的軟件棧和控制開銷。所以當(dāng)程序的計(jì)算規(guī)模不大時(shí)，使用多GPU虛擬化平臺(tái)往往不能得到很好的結(jié)果。第4節(jié)的實(shí)驗(yàn)結(jié)果可以證明，當(dāng)計(jì)算規(guī)模比較大的時(shí)，使用多個(gè)GPU是可以抵消這些開銷所帶來的性能損失從而提升程序的執(zhí)行效率。

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

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

實(shí)驗(yàn)中的后端節(jié)點(diǎn)是兩臺(tái)配置Inter(R) Core(TM) i5-4590CPU(3.3 GHz)處理器，4 GB內(nèi)存和100 GB硬盤，GeForce GTX750 Ti GPU，Ubuntu 16.04和Ubuntu 14.04 64位操作系統(tǒng)，CUDA版本分別為6.5和7.5；前端節(jié)點(diǎn)是一臺(tái)物理機(jī)，配置Celeron(R) Dual-Core CPU T3000(1.8 GHz)處理器，沒有NVIDIA顯卡，也沒有安裝CUDA程序，Ubuntu 14.04 64位操作系統(tǒng)；前端與后端節(jié)點(diǎn)通過百兆以太網(wǎng)互連。

4.2 實(shí)驗(yàn)內(nèi)容

實(shí)驗(yàn)運(yùn)行的程序基于CUDA框架使用EM(Expectation Maximization)算法在高斯混合模型(Gaussian Mixture Model)下進(jìn)行數(shù)據(jù)聚類，原程序可以使用單個(gè)節(jié)點(diǎn)上的多個(gè)GPU進(jìn)行加速，是CLUSTER[10]的GPU實(shí)現(xiàn)，程序有單節(jié)點(diǎn)單GPU和單節(jié)點(diǎn)多GPU兩個(gè)不同的執(zhí)行模式，當(dāng)探測(cè)到節(jié)點(diǎn)中的GPU數(shù)目多于一個(gè)時(shí)，會(huì)啟用多個(gè)線程控制多個(gè)GPU來加速程序的執(zhí)行，實(shí)驗(yàn)使用的數(shù)據(jù)集是用Matlab生成的，所有不同類型的程序都是在同一個(gè)數(shù)據(jù)集上執(zhí)行。實(shí)驗(yàn)中分別在前端節(jié)點(diǎn)上使用本地CPU和通過虛擬化平臺(tái)使用1個(gè)、2個(gè)遠(yuǎn)程GPU計(jì)算同樣的輸入數(shù)據(jù)集，后端節(jié)點(diǎn)配置了相同類型的GPU，只是CUDA 版本和操作系統(tǒng)版本有區(qū)別。虛擬化平臺(tái)為基于ZeroMQ通信方式的多GPU虛擬化方案。

圖8中橫軸代表的是初始時(shí)cluster的數(shù)目，不同的數(shù)目會(huì)影響程序的執(zhí)行時(shí)間，所以使用這個(gè)參數(shù)來做對(duì)比，縱軸表示整個(gè)程序運(yùn)行的時(shí)間。隨著初始cluster的值增加，使用CPU處理花費(fèi)的時(shí)間增長更快，使用GPU獲得的加速比也越大，當(dāng)初始有200個(gè)cluster時(shí)使用1個(gè)GPU比CPU獲得6.1的加速比，而使用2個(gè)GPU時(shí)與使用1個(gè)GPU獲得1.85的加速比，實(shí)驗(yàn)中繼續(xù)增加cluster時(shí)，獲得的加速比并沒有繼續(xù)增加。

圖8 使用不同設(shè)備時(shí)程序運(yùn)行的時(shí)間

實(shí)驗(yàn)中計(jì)算得到了許多參數(shù)，如均值、協(xié)方差等，表1中的系數(shù)π實(shí)際上是每個(gè)component被選中的概率，并不指代圓周率，實(shí)驗(yàn)中運(yùn)行的GMM程序會(huì)得到三個(gè)系數(shù)；CPU列是使用CPU計(jì)算出來的系數(shù)π的值，GPU列是使用GPU計(jì)算出來的系數(shù)π的值。可以看出，對(duì)于同樣的輸入數(shù)據(jù)集，對(duì)于不同的初始cluster，使用GPU計(jì)算得到的系數(shù)與使用CPU計(jì)算的到的系數(shù)有些許的誤差，這是由于實(shí)驗(yàn)中使用的GPU與CPU處理浮點(diǎn)數(shù)據(jù)的精度不同以及小數(shù)的舍入導(dǎo)致的，并不是虛擬化平臺(tái)影響了程序的正確性。

表1 不同平臺(tái)上執(zhí)行得到的compunent的系數(shù)

續(xù)表1

以上可知，虛擬化平臺(tái)可以保證程序正確性的情況下，獲得比使用CPU時(shí)更好的性能，只使用兩個(gè)GPU時(shí)，就可以獲得十倍的加速比；GPU的數(shù)目增加時(shí)可以獲得更大的加速比，但是還未達(dá)到線性的加速比。這是因?yàn)樵谟卸鄠€(gè)GPU時(shí)會(huì)涉及更多的數(shù)據(jù)交換和參數(shù)控制，網(wǎng)絡(luò)傳輸?shù)难訒r(shí)也會(huì)增加，新增加的軟件棧也會(huì)影響效率，這些是虛擬化所無法避免的開銷。

4.3 實(shí)驗(yàn)結(jié)論

基于虛擬化的多GPU通用計(jì)算平臺(tái)上，原來基于單機(jī)多GPU實(shí)現(xiàn)的GMM程序不需要修改源代碼就可以運(yùn)行在沒有NVIDIA顯卡的前端節(jié)點(diǎn)上。通過調(diào)用兩個(gè)遠(yuǎn)程GPU就能夠獲得比使用CPU時(shí)十倍以上的加速比，并且只需要修改一些配置文件就可以方便地增減所使用的GPU數(shù)目，十分靈活。雖然虛擬化帶來了一定的性能損失，但是可以有效地實(shí)現(xiàn)單機(jī)多GPU和多機(jī)多GPU的編程模式統(tǒng)一。

5 結(jié) 語

實(shí)現(xiàn)了基于虛擬化的多GPU通用計(jì)算平臺(tái)，可以十分方便地使用遠(yuǎn)程GPU進(jìn)行通用計(jì)算。能夠使用分布式環(huán)境中不同節(jié)點(diǎn)上的多個(gè)GPU加速程序，且不需要對(duì)源碼做太多的修改。最后在實(shí)驗(yàn)中驗(yàn)證了該平臺(tái)的有效性。

實(shí)驗(yàn)中發(fā)現(xiàn)網(wǎng)絡(luò)性能對(duì)于平臺(tái)的性能有很大的影響，如果使用高速網(wǎng)絡(luò)如InfiniBand將會(huì)提高虛擬化平臺(tái)的性能，此外，還有GPU RMDA技術(shù)，多GPU使用時(shí)的P2P問題等能夠提升性能的技術(shù)可以應(yīng)用到虛擬化平臺(tái)上。

[1] Duato J,Pena A J,Silla F,et al.rCUDA:Reducing the number of GPU-based accelerators in high performance clusters[C]//High Performance Computing and Simulation (HPCS),2010 International Conference on.IEEE,2010:224-231.

[2] Shi L,Chen H,Sun J,et al.vCUDA:GPU-accelerated high-performance computing in virtual machines[J].IEEE Transactions on Computers,2012,61(6):804-816.

[3] 石林.GPU通用計(jì)算虛擬化方法研究[D].湖南大學(xué),2012.

[4] Giunta G,Montella R,Agrillo G,et al.A GPGPU transparent virtualization component for high performance computing clouds[C]//European Conference on Parallel Processing.Springer Berlin Heidelberg,2010:379-391.

[5] Gupta V,Gavrilovska A,Schwan K,et al.GViM:GPU-accelerated virtual machines[C]//Proceedings of the 3rd ACM Workshop on System-level Virtualization for High Performance Computing.ACM,2009:17-24.

[6] 仝伯兵,楊昕吉,謝振平,等.GPU虛擬化技術(shù)及應(yīng)用研究[J].軟件導(dǎo)刊,2015,14(6):153-156.

[7] Suzuki Y,Kato S,Yamada H,et al.GPUvm: why not virtualizing GPUs at the hypervisor?[C]//Usenix Conference on Usenix Technical Conference.USENIX Association,2014:109-120.

[8] Liu M,Li T,Jia N,et al.Understanding the virtualization “Tax” of scale-out pass-through GPUs in GaaS clouds:An empirical study[C]//IEEE,International Symposium on High PERFORMANCE Computer Architecture.IEEE,2015:259-270.

[9] 楊經(jīng)緯,馬凱,龍翔.面向集群環(huán)境的虛擬化GPU計(jì)算平臺(tái)簡[J].北京航空航天大學(xué)學(xué)報(bào),2016,42(11):2340-2348.

[10] Bouman C A,Shapiro M,Ncsa,et al.Cluster:An unsupervised algorithm for modeling Gaussian mixtures[J].Soft Manual,2005.

[11] Castelló A,Duato J,Mayo R,et al.On the use of remote GPUs and low-power processors for the acceleration of scientific applications[C]//The Fourth International Conference on Smart Grids,Green Communications and IT Energy-aware Technologies (ENERGY),2014:57-62.

[12] Sourouri M,Gillberg T,Baden S B,et al.Effective multi-GPU communication using multiple CUDA streams and threads[C]//2014 USENIX Annual Technical Conference Parallel and Distributed Systems (ICPADS).IEEE,2014:981-986.

[13] Gottschlag M,Hillenbrand M,Kehne J,et al.LoGV:Low-Overhead GPGPU Virtualization[C]//IEEE,International Conference on High PERFORMANCE Computing and Communications & 2013 IEEE International Conference on Embedded and Ubiquitous Computing.IEEE,2014:1721-1726.

[14] Yang C T,Liu J C,Wang H Y,et al.Implementation of GPU virtualization using PCI pass-through mechanism[J].The Journal of Supercomputing,2014,68(1):183-213.

[15] 張玉潔.基于多GPGPU并行計(jì)算的虛擬化技術(shù)研究[D].南京航空航天大學(xué),2015.

[16] 閔芳,張志先,張玉潔.虛擬化環(huán)境下多GPU并行計(jì)算研究[J].微電子學(xué)與計(jì)算機(jī),2016,33(3):69-75.

[17] 張玉潔,呂相文,張?jiān)浦?GPU虛擬化環(huán)境下的數(shù)據(jù)通信策略研究[J].計(jì)算機(jī)技術(shù)與發(fā)展,2015,25(8):24-28.

[18] 張?jiān)浦?虛擬化環(huán)境下的GPU通用計(jì)算關(guān)鍵技術(shù)研究[D].南京航空航天大學(xué),2014.

[19] 王剛,唐杰,武港山.基于多GPU集群的編程框架[J].計(jì)算機(jī)技術(shù)與發(fā)展,2014,24(1):9-13.

[20] 陳志佳,朱元昌,邸彥強(qiáng),等.一種改進(jìn)的GPU虛擬化實(shí)施方法[J].計(jì)算機(jī)工程與科學(xué),2015,37(5):901-906.

RESEARCHOFPARALLELCOMPUTINGPLATFORMOFMULTI-GPUBASEDONVIRTUALENVIRONMENT

Xu Heng1,3Wu Junmin2,3Yang Zhigang2Yin Yan2

1(SchoolofSoftware,UniversityofScienceandTechnologyofChina,Hefei230027,Anhui,China)2(SchoolofComputerScienceandTechnology,UniversityofScienceandTechnologyofChina,Hefei230027,Anhui,China)3(SuzhouInstituteforAdvancedStudy,UniversityofScienceandTechnologyofChina,Suzhou215123,Jiangsu,China)

Aiming at the distributed multi-node and multi-GPUs system environment, a general computing virtualization platform of multi-GPUs based on CUDA framework is implemented. The application program can use the remote GPUs in the same way as the local GPUs. The original CUDA application program can be run on the virtual platform of GPUs without modification or with only a few changes, in order to achieve unity in the programming model of single multi-GPUs and multi-machine multi-GPUs. In the end, we verify the correctness of the experiment through a Gaussian mixture model for data classification by CUDA. The experiment shows that the result of a program using two remote GPUs can get about ten times faster than using the original CPU without affecting the correctness.

Virtualization GPU Multi-machine and multi-GPU Distributed

2017-01-04。國家重點(diǎn)研發(fā)計(jì)劃項(xiàng)目(2016YFB1000403)。徐恒，碩士生，主研領(lǐng)域：GPU通用計(jì)算，虛擬化。吳俊敏，副教授。楊志剛，碩士生。尹燕，博士生。

TP3

A

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