王 浩，王浩楓

(中國航天科工集團(tuán)第二研究院 七〇六所，北京 100854)

0 引 言

隨著處理器的發(fā)展，異構(gòu)計(jì)算機(jī)系統(tǒng)已經(jīng)成為計(jì)算機(jī)架構(gòu)的一大研究熱點(diǎn)，異構(gòu)編程也得到了飛速發(fā)展，其中OpenCL[1]憑借良好的可移植性得到廣泛應(yīng)用。OpenCL標(biāo)準(zhǔn)規(guī)定設(shè)備與命令隊(duì)列高度耦合，程序需在編碼階段靜態(tài)指定任務(wù)調(diào)度方案，這不僅對開發(fā)人員是一大難題，也對多任務(wù)下的資源分配帶來了極大的苦難。

目前，面向OpenCL多任務(wù)的研究主要包括靜態(tài)方法和動(dòng)態(tài)方法。靜態(tài)方法是通過預(yù)先執(zhí)行的方式，獲取任務(wù)在不同設(shè)備上的執(zhí)行信息，進(jìn)一步通過元啟發(fā)式算法確定調(diào)度方案并進(jìn)行程序編碼。動(dòng)態(tài)方法主要包括任務(wù)在線分析和任務(wù)調(diào)度兩部分，采用任務(wù)在線分析的方法替代靜態(tài)方法中的程序預(yù)執(zhí)行，再根據(jù)任務(wù)分析結(jié)果，結(jié)合異構(gòu)調(diào)度算法對任務(wù)進(jìn)行動(dòng)態(tài)調(diào)度。傳統(tǒng)動(dòng)態(tài)調(diào)度一方面任務(wù)分析不考慮任務(wù)間資源競爭導(dǎo)致多任務(wù)場景下任務(wù)分析不準(zhǔn)確，另一方面?zhèn)鹘y(tǒng)研究忽視OpenCL數(shù)據(jù)傳輸導(dǎo)致的時(shí)間開銷，使得任務(wù)分析偏差較大，進(jìn)一步影響調(diào)度效果。

本文提出了一個(gè)新穎的調(diào)度框架，它能夠在資源競爭環(huán)境下確定最佳任務(wù)分配。一方面，該框架考慮了OpenCL內(nèi)核行為對設(shè)備硬件特性的適應(yīng)性。另一方面，也考慮了動(dòng)態(tài)設(shè)備和內(nèi)核特性(如設(shè)備負(fù)載、內(nèi)核數(shù)據(jù)大小等)對系統(tǒng)中任務(wù)調(diào)度的影響，該調(diào)度算法考慮系統(tǒng)總體負(fù)載均衡的同時(shí)保證了單個(gè)任務(wù)的執(zhí)行效率。

1 研究現(xiàn)狀

本節(jié)展示了當(dāng)前異構(gòu)調(diào)度方法的研究現(xiàn)狀和存在的問題。

目前已經(jīng)提出了幾種OpenCL任務(wù)調(diào)度方法。Fang J等[2]提出了一種基于異構(gòu)多處理器的匹配度調(diào)度算法，該算法通過將任務(wù)靜態(tài)特征和處理器核心特征映射到相同的歐氏空間來計(jì)算任務(wù)與處理器的距離值，使用加權(quán)歐氏距離作為調(diào)度的依據(jù)。Al-Zoubi A等[3]提出了一個(gè)基于模糊邏輯分類器的CPU-GPU-FPGA異構(gòu)平臺的調(diào)度框架。該框架使用OpenCL即時(shí)編譯器從OpenCL內(nèi)核的抽象語法樹中提取靜態(tài)代碼特征，并與運(yùn)行時(shí)特征相結(jié)合，將OpenCL內(nèi)核調(diào)度到高并行度內(nèi)核(GPU和FPGA)或低并行度內(nèi)核(CPU)。Aji A M等[4]提出了建立在SnuCL基礎(chǔ)上的MultiCL調(diào)度框架，通過將內(nèi)核啟動(dòng)與高級命令隊(duì)列而不是實(shí)際的物理設(shè)備相關(guān)聯(lián)，使調(diào)度器能夠在內(nèi)核啟動(dòng)時(shí)動(dòng)態(tài)地選擇合適的設(shè)備。MultiCL使用機(jī)器學(xué)習(xí)算法來預(yù)測內(nèi)核在不同設(shè)備上的執(zhí)行時(shí)間，作為內(nèi)核剖析時(shí)調(diào)度的基礎(chǔ)。雖然上述方法取得了一些成果，但在多任務(wù)資源競爭的情況下，但是他們不考慮設(shè)備的負(fù)載情況，將任務(wù)大量映射到高速設(shè)備上，使系統(tǒng)負(fù)載極不均衡。在高競爭場景下，部分任務(wù)出現(xiàn)了2倍～3倍的執(zhí)行效率下降。

部分研究[5-8]假定GPU是任務(wù)獨(dú)占性的，即一旦一個(gè)任務(wù)獲得了對GPU的訪問權(quán)，在當(dāng)前任務(wù)完成之前，其它任務(wù)不能使用GPU。隨著GPU和OpenCL技術(shù)的發(fā)展，MPI+OpenCL已經(jīng)被廣泛使用。GPU已經(jīng)可以并行地執(zhí)行不同的OpenCL內(nèi)核。上述研究給出的調(diào)度方案極大偏離實(shí)際情況，單任務(wù)獨(dú)占設(shè)備的方案浪費(fèi)了大量計(jì)算資源。

因此，鑒于當(dāng)前研究的不足，本文考慮資源競爭對OpenCL內(nèi)核執(zhí)行的影響，提出了面向CPUs-GPUs系統(tǒng)的OpenCL任務(wù)調(diào)度框架，緩解異構(gòu)調(diào)度算法在資源競爭環(huán)境下的性能下降現(xiàn)象，保障CPU-GPU異構(gòu)系統(tǒng)的高效性。

為了驗(yàn)證設(shè)備負(fù)載對任務(wù)執(zhí)行時(shí)間的影響，選取宇宙學(xué)中最常用的N體運(yùn)動(dòng)模擬程序N-Body作為測試程序，實(shí)驗(yàn)設(shè)備為Nvidia Titan RTX，軟件環(huán)境為CUDA 10.0 SDK，操作系統(tǒng)為Ubuntu 16.04，模擬輸入為1000個(gè)天體，記錄N-Body程序在設(shè)備Nvidia Titan RTX預(yù)先設(shè)置不同負(fù)載情況下的執(zhí)行時(shí)間。

圖1顯示了N-Body基準(zhǔn)測試在不同的GPU爭用情況下的運(yùn)行時(shí)間(單位ms)。從圖中可以看出，在低負(fù)載時(shí)，即使有其它OpenCL內(nèi)核在GPU中執(zhí)行，對N-Body的執(zhí)行時(shí)間幾乎沒有影響。隨著負(fù)載的增加，負(fù)載程序和N-Body之間存在著明顯的資源競爭，N-Body的執(zhí)行時(shí)間明顯增加，大約是低負(fù)載時(shí)的2.7倍。

圖1 N-Body在不同負(fù)載下的GPU爭用 情況下的運(yùn)行時(shí)間

上述實(shí)驗(yàn)結(jié)果表明，資源競爭對OpenCL內(nèi)核執(zhí)行效率存在較大影響，從實(shí)驗(yàn)角度進(jìn)一步驗(yàn)證了上述調(diào)度算法研究忽略資源競爭的不合理性。

2 調(diào)度框架介紹

OpenCL多任務(wù)調(diào)度系統(tǒng)包括3層：硬件、系統(tǒng)軟件、OpenCL任務(wù)調(diào)度層。OpenCL多任務(wù)調(diào)度系統(tǒng)如圖2所示。硬件層是最底層，由基于CPU和GPU構(gòu)成的異構(gòu)多核計(jì)算機(jī)構(gòu)成，包含多個(gè)CPU和GPU，其中OpenCL主機(jī)程序運(yùn)行在CPU上，OpenCL內(nèi)核既可以運(yùn)行在CPU上也可以運(yùn)行在GPU上，主機(jī)程序通過直接訪問或者PCIe總線訪問設(shè)備。硬件層的頂部是系統(tǒng)軟件層，由操作系統(tǒng)和OpenCL運(yùn)行時(shí)組成，為OpenCL程序運(yùn)行提供軟件支持的同時(shí)，為上層調(diào)度系統(tǒng)提供相關(guān)的設(shè)備信息，操作系統(tǒng)提供設(shè)備負(fù)載等信息查詢接口，OpenCL運(yùn)行時(shí)提供OpenCL設(shè)備性能等相關(guān)信息。OpenCL多任務(wù)調(diào)度程序位于異構(gòu)系統(tǒng)的最頂層。系統(tǒng)中的用戶提交了不同的OpenCL程序，調(diào)度系統(tǒng)利用任務(wù)估計(jì)模塊對任務(wù)隊(duì)列中的任務(wù)進(jìn)行評估，量化每一個(gè)OpenCL內(nèi)核調(diào)度到不同設(shè)備上的開銷，由OpenCL內(nèi)核調(diào)度器將內(nèi)核調(diào)度到不同設(shè)備關(guān)聯(lián)的命令隊(duì)列中，由OpenCL運(yùn)行時(shí)完成命令隊(duì)列中的相關(guān)命令分配，直到命令完成。

圖2 調(diào)度框架構(gòu)成

本文提出的調(diào)度框架主要包括任務(wù)估計(jì)模塊，數(shù)據(jù)傳輸分析模塊和調(diào)度模塊。任務(wù)估計(jì)模塊又包括內(nèi)核特征提取，設(shè)備特征提取和任務(wù)估計(jì)部分，特征提取模塊作為任務(wù)估計(jì)模塊的輸入，由任務(wù)估計(jì)模塊評估內(nèi)核在設(shè)備上的運(yùn)行時(shí)間。數(shù)據(jù)傳輸分析則是量化OpenCL內(nèi)核所帶來的數(shù)據(jù)傳輸開銷。任務(wù)調(diào)度模塊則是根據(jù)上述模塊的輸出，為OpenCL內(nèi)核選擇合適的設(shè)備進(jìn)行調(diào)度。

3 任務(wù)估計(jì)

3.1 內(nèi)核特征提取

圖3 內(nèi)核特征提取流程

通過LLVM中間層語言來分析kernel，能夠盡可能多獲取kernel的靜態(tài)特征，規(guī)避了直接分析kernel代碼而導(dǎo)致的特征提取不充分的問題。LLVM匯編代碼比抽象語法樹更清楚地反映了OpenCL內(nèi)核的行為。

除了靜態(tài)代碼特征外，還利用運(yùn)行時(shí)參數(shù)來描述內(nèi)核的動(dòng)態(tài)特征和并行性質(zhì)。內(nèi)核的動(dòng)態(tài)特性主要與數(shù)據(jù)的大小和線程的數(shù)量有關(guān)。根據(jù)OpenCL API所提供的函數(shù)獲取OpenCL運(yùn)行時(shí)的內(nèi)核動(dòng)態(tài)特征，包括創(chuàng)建對象、數(shù)據(jù)傳輸、kernel啟動(dòng)函數(shù)。創(chuàng)建內(nèi)存對象功能參數(shù)主要包括內(nèi)存大小、內(nèi)存種類標(biāo)簽、主機(jī)地址。數(shù)據(jù)傳輸功能參數(shù)主要包括傳輸模式、傳輸數(shù)據(jù)量大小。OpenCL內(nèi)核啟動(dòng)功能參數(shù)主要包括工作組數(shù)目，工作項(xiàng)數(shù)目和內(nèi)核對象。

提取的內(nèi)核特征見表1。

表1 內(nèi)核特征

上述特征不僅包括內(nèi)核行為，還包括內(nèi)核結(jié)構(gòu)，以及函數(shù)、內(nèi)存等使用情況。

3.2 設(shè)備特征提取

現(xiàn)有研究中的設(shè)備靜態(tài)特征僅包括OpenCL設(shè)備的硬件固有屬性，包括核心數(shù)、L1 Cache大小、L2 Cache大小、內(nèi)存大小等。然而，單純通過系統(tǒng)自帶的設(shè)備管理器所獲得的硬件屬性很難準(zhǔn)確表征OpenCL設(shè)備的性能。該方案的設(shè)備特征提取器除了硬件本身的結(jié)構(gòu)特征外，創(chuàng)新性地將基準(zhǔn)分?jǐn)?shù)作為設(shè)備特征的一部分。設(shè)備特征提取模塊集成了Geekbench 5基準(zhǔn)測試程序來獲得設(shè)備在不同方面的性能分?jǐn)?shù)[10]。設(shè)備特征提流程如圖4所示。

圖4 設(shè)備特征提取流程

設(shè)備特征提取器維護(hù)一個(gè)設(shè)備信息的數(shù)據(jù)庫。當(dāng)OpenCL程序在讀取平臺下設(shè)備的時(shí)候，該框架根據(jù)OpenCL平臺所獲取的設(shè)備基本信息去設(shè)備信息表中查找對應(yīng)的條目，如果存在該條目的完整信息，則從數(shù)據(jù)庫中讀取相應(yīng)的設(shè)備信息，如果沒有，則通過運(yùn)行對應(yīng)的Geekbench 5基準(zhǔn)測試程序，獲取其相關(guān)信息，并填入設(shè)備信息表中。該方法使得該框架能夠在運(yùn)行過程中不斷擴(kuò)充硬件信息，保證了該框架可以在各種硬件環(huán)境中廣泛使用。

設(shè)備動(dòng)態(tài)特征主要用于描述設(shè)備的運(yùn)行狀態(tài)，包括設(shè)備負(fù)載、內(nèi)存使用和溫度。特征提取模塊通過操作系統(tǒng)層和OpenCL運(yùn)行時(shí)接口獲取上述信息。設(shè)備靜態(tài)特征與動(dòng)態(tài)特征相結(jié)合能很好表示該設(shè)備剩余計(jì)算資源的數(shù)目，有效反映對后續(xù)調(diào)度的影響，是該框架可以適用于任務(wù)資源競爭環(huán)境的重要保證。

表2展示了設(shè)備特征提取器所涉及的設(shè)備特征。

上述設(shè)備特征不僅包含基本硬件特征，還包括性能得分，與OpenCL內(nèi)核行為相對應(yīng)，有利于調(diào)度模塊學(xué)習(xí)設(shè)備與OpenCL內(nèi)核的映射關(guān)系，其次設(shè)備的動(dòng)態(tài)特征能夠很好表示系統(tǒng)中資源爭用情況，對后續(xù)調(diào)度具有重要意義。

3.3 模型構(gòu)建

任務(wù)估計(jì)模塊通過構(gòu)造一個(gè)基于機(jī)器學(xué)習(xí)的模型來預(yù)測內(nèi)核的執(zhí)行時(shí)間。建立一個(gè)基于機(jī)器學(xué)習(xí)的模型需要收集訓(xùn)練數(shù)據(jù)。為了使訓(xùn)練的模型獲得良好的泛化效果，從AMD APP Code Samples、Nvidia OpenCL Code Samples，Intel OpenCL SDK sample programs中選擇了85個(gè)基準(zhǔn)測試程序。在不同負(fù)載的不同設(shè)備上運(yùn)行它們，記錄OpenCL內(nèi)核和設(shè)備的靜態(tài)與運(yùn)行時(shí)特征，并記錄應(yīng)用的計(jì)算時(shí)間，得到訓(xùn)練數(shù)據(jù)約5000條，上述基準(zhǔn)程序涵蓋了數(shù)值計(jì)算、圖像處理、加密算法、機(jī)器學(xué)習(xí)，幾乎包含了大多數(shù)應(yīng)用類型，使得訓(xùn)練數(shù)據(jù)能夠覆蓋常見的OpenCL應(yīng)用程序。為接下來的模型訓(xùn)練提供良好的數(shù)據(jù)基礎(chǔ)。

表2 設(shè)備特征

本文采用K最鄰近算法(K-nearest neighbor，KNN)、支持向量機(jī)(support vector machine，SVM)、隨機(jī)森林(random forest，RF)、樸素貝葉斯(Naive Bayes，NB)和貝葉斯網(wǎng)絡(luò)(bayesian network，BN)這5種預(yù)測模型進(jìn)行訓(xùn)練，得到模型在測試集上的預(yù)測的可決系數(shù)。

圖5展示了，上述5類常見算法在測試集上的預(yù)測模型可決系數(shù)的變化。

圖5 特征篩選后各算法預(yù)測準(zhǔn)確率

選擇KNN、SVM、RF、NB和BN作為對比算法的主要原因是該框架作為運(yùn)行時(shí)調(diào)度框架，具有強(qiáng)實(shí)時(shí)性。較為復(fù)雜的算法，受限于計(jì)算時(shí)間難以滿足實(shí)時(shí)性需求，因此選取這些常見且簡單模型。文獻(xiàn)[11]驗(yàn)證了復(fù)雜算法在實(shí)時(shí)調(diào)度領(lǐng)域應(yīng)用的難點(diǎn)，僅能支持上述幾種簡單模型和三層的神經(jīng)網(wǎng)絡(luò)。針對XGboost和復(fù)雜神經(jīng)網(wǎng)絡(luò)等較為復(fù)雜的模型算法，實(shí)時(shí)性方面表現(xiàn)較差。隨機(jī)森林算法具有很好的預(yù)測準(zhǔn)確性的同時(shí)，還具有很好的抗噪聲能力。根據(jù)上述分析選取隨機(jī)森林算法構(gòu)建任務(wù)估計(jì)模型。

4 數(shù)據(jù)傳輸

OpenCL平臺模型由主機(jī)和多個(gè)OpenCL設(shè)備構(gòu)成，除了內(nèi)核部分外，OpenCL程序中均在主機(jī)上運(yùn)行，而內(nèi)核則在OpenCL設(shè)備上運(yùn)行。該平臺模型的結(jié)構(gòu)導(dǎo)致主機(jī)和OpenCL設(shè)備間存在不可避免的數(shù)據(jù)交互。隨著應(yīng)用數(shù)據(jù)規(guī)模的增加，以及數(shù)據(jù)傳輸速率發(fā)展遠(yuǎn)遠(yuǎn)跟不上處理器運(yùn)算速率的發(fā)展速度，數(shù)據(jù)傳輸已經(jīng)成為OpenCL高性能計(jì)算的一大瓶頸[12]。

本文框架借鑒現(xiàn)有的研究[13,14]等對于數(shù)據(jù)傳輸采用了簡化處理，假設(shè)在OpenCL平臺中，內(nèi)核調(diào)度到CPU中時(shí)，內(nèi)核可以直接訪問內(nèi)存，數(shù)據(jù)傳輸時(shí)間為0；內(nèi)核調(diào)度到GPU時(shí)數(shù)據(jù)傳輸時(shí)間僅和數(shù)據(jù)傳輸規(guī)模和PCIe總線帶寬有關(guān)，用公式表示如下

其中，tGPU表示數(shù)據(jù)傳輸?shù)紾PU所需要的時(shí)間，tCPU表示數(shù)據(jù)傳輸?shù)紺PU所需要的時(shí)間，Sdata表示數(shù)據(jù)的大小，BdPCIe表示總線帶寬。

該公式有一定的借鑒意義，但是也有一定的不合理性。數(shù)據(jù)傳輸命令的生命周期包括命令入隊(duì)、命令調(diào)度、命令載入、命令啟動(dòng)、命令執(zhí)行和命令結(jié)束部分，其中命令入隊(duì)到命令啟動(dòng)是數(shù)據(jù)傳輸啟動(dòng)的固有開銷；命令執(zhí)行則是數(shù)據(jù)傳輸過程，OpenCL包含多種緩沖區(qū)和數(shù)據(jù)傳輸模式，傳輸速度有明顯差異，通過理論和實(shí)驗(yàn)分析提出了新的數(shù)據(jù)傳輸量化公式

5 調(diào)度模型

本文提出的異構(gòu)調(diào)度算法包含兩個(gè)目標(biāo)：負(fù)載均衡和單任務(wù)執(zhí)行時(shí)間。負(fù)載均衡定義為將負(fù)載(工作任務(wù))進(jìn)行平衡、分?jǐn)偟蕉鄠€(gè)處理單元上進(jìn)行執(zhí)行，是衡量系統(tǒng)中不同處理單元任務(wù)分配的均衡程度。單任務(wù)執(zhí)行時(shí)間是衡量單個(gè)任務(wù)執(zhí)行效率的最常用指標(biāo)。

為了衡量一個(gè)OpenCL調(diào)度到某個(gè)設(shè)備上的負(fù)載變化情況，提出通過OpenCL內(nèi)核的并行度，即工作組和工作組中工作項(xiàng)數(shù)目的乘積來表示OpenCL內(nèi)核所需要的計(jì)算資源，該理念符合OpenCL執(zhí)行模型和CPU-GPU的體系結(jié)構(gòu)。OpenCL內(nèi)核在OpenCL啟動(dòng)時(shí)，根據(jù)OpenCL API的相關(guān)指令，將設(shè)備上的OpenCL內(nèi)核按照指定維度進(jìn)行劃分，內(nèi)核依據(jù)偏移量平鋪到設(shè)備對應(yīng)的內(nèi)核。OpenCL內(nèi)核工作項(xiàng)映射到內(nèi)核由硬件實(shí)現(xiàn)保證，映射方式比較靈活，現(xiàn)在設(shè)備并不按照偏移量進(jìn)行映射。當(dāng)設(shè)備計(jì)算資源充足時(shí)，即當(dāng)前剩余核心數(shù)目大于等于OpenCL內(nèi)核啟動(dòng)命令設(shè)置的工作項(xiàng)數(shù)目時(shí)，該內(nèi)核的所有工作組可同時(shí)執(zhí)行；當(dāng)設(shè)備計(jì)算資源不足時(shí)，即當(dāng)前剩余核心數(shù)目小于OpenCL內(nèi)核啟動(dòng)命令設(shè)置的工作項(xiàng)數(shù)目時(shí)，一部分工作組中的工作項(xiàng)先行執(zhí)行，其它工作項(xiàng)阻塞，直到有工作項(xiàng)執(zhí)行結(jié)束，再將工作項(xiàng)調(diào)度到空閑核心上。工作項(xiàng)映射到OpenCL核心的方式驗(yàn)證了本文提出的設(shè)備負(fù)載量化機(jī)制，能夠準(zhǔn)確預(yù)測OpenCL內(nèi)核調(diào)度到設(shè)備上所造成的負(fù)載影響。

因此通過如下公式估計(jì)內(nèi)核調(diào)度到指定設(shè)備后，該設(shè)備的計(jì)算資源使用情況表示為

其中，Li表示設(shè)備i的計(jì)算資源使用情況，CRJi表示內(nèi)核調(diào)度到設(shè)備i后(實(shí)際未調(diào)度)，設(shè)備i上執(zhí)行內(nèi)核工作項(xiàng)數(shù)組之和，Corei表示設(shè)備i所具有的OpenCL(CUDA)核心數(shù)目。

因此，得到系統(tǒng)的負(fù)載均衡程度Comload， 定義如下

其中，μ表示系統(tǒng)中設(shè)備的平均負(fù)載，μ按照如下公式計(jì)算

如果僅采用負(fù)載均衡程度作為調(diào)度依據(jù)，會(huì)導(dǎo)致大量內(nèi)核被調(diào)度到低速設(shè)備上，使得任務(wù)執(zhí)行效率下降，因此結(jié)合負(fù)載均衡度和任務(wù)執(zhí)行效率，提出調(diào)度評價(jià)函數(shù)f(Ji,Pi)， 計(jì)算公式如下

其中，α表示獨(dú)立參數(shù)，用來調(diào)整內(nèi)核執(zhí)行時(shí)間和系統(tǒng)整體負(fù)載均衡度之間的占比，可根據(jù)實(shí)際應(yīng)用場景需求，調(diào)整參數(shù)盡可能對單任務(wù)執(zhí)行時(shí)間和系統(tǒng)負(fù)載進(jìn)行折衷處理。Tji表示按照OpenCL調(diào)度開銷模型估計(jì)內(nèi)核Jj調(diào)度到設(shè)備Pi的時(shí)間開銷，Tmin和Tmax表示按照OpenCL調(diào)度開銷模型估計(jì)內(nèi)核Jj調(diào)度到系統(tǒng)中設(shè)備的最短時(shí)間和最長時(shí)間開銷。Tji包括任務(wù)估計(jì)模塊對內(nèi)核執(zhí)行時(shí)間估計(jì)以及數(shù)據(jù)傳輸開銷，由如下公式計(jì)算

因此整個(gè)調(diào)度框架流程如圖6所示。

圖6 調(diào)度算法流程

上述步驟展示了OpenCL任務(wù)的一個(gè)內(nèi)核調(diào)度的完整過程，當(dāng)前內(nèi)核處理結(jié)束后，該程序按照任務(wù)提交的順序，逐個(gè)處理直到所有任務(wù)執(zhí)行結(jié)束。

6 實(shí) 驗(yàn)

在這一節(jié)中，將描述本文的實(shí)驗(yàn)設(shè)置和所使用的評估指標(biāo)及方法。

6.1 實(shí)驗(yàn)設(shè)置

在兩個(gè)CPU-GPU異構(gòu)系統(tǒng)上評估本文提出的方法。其中一個(gè)系統(tǒng)包含兩塊Intel(R) Xeon(R) Gold 6151@3.00GHz CPU和8塊NVIDIA Titan RTX，第二個(gè)系統(tǒng)包含一塊Intel Core i7-10870H CPU和兩塊AMD Radeon RX 6900 XT。實(shí)驗(yàn)使用OpenCL SDK包括NVIDIA CUDA Toolkit 10.1，Intel SDK for OpenCLTMApplications和AMD APP SDK 3.0。系統(tǒng)一的操作系統(tǒng)為Ubuntu 16.04，系統(tǒng)二的操作系統(tǒng)為Windows 10。硬件平臺的詳情見表3。

表3 硬件平臺信息

系統(tǒng)一包含兩個(gè)OpenCL平臺，分別為Intel和Nvidia平臺，Intel平臺下有兩個(gè)設(shè)備，Nvidia平臺下有8個(gè)設(shè)備，OpenCL版本為2.0。系統(tǒng)二也包含兩個(gè)OpenCL平臺，分別為Intel和AMD平臺，Intel平臺下有一個(gè)設(shè)備，Nvidia平臺下有兩個(gè)設(shè)備，OpenCL版本為分別為1.2和3.0。上述OpenCL運(yùn)行時(shí)和操作系統(tǒng)共同構(gòu)成了測試的軟件層。

實(shí)驗(yàn)選擇了兩個(gè)主流基準(zhǔn)套件(Parboil OpenCL基準(zhǔn)套件和Ploybench基準(zhǔn)套件)來驗(yàn)證該框架的性能。主要包括Parboil基準(zhǔn)套件BFS、Cutup、Sgemm和Spmv等程序以及Ploybench基準(zhǔn)套件中的ATAX、BICG、CORR、GESUMMV和SYRK等程序，輸入規(guī)模為4 M-1 G。上述兩個(gè)基準(zhǔn)測試在OpenCL調(diào)度系統(tǒng)性能測試中具有很好的代表性，在諸多論文實(shí)驗(yàn)中廣泛應(yīng)用。

為了能夠驗(yàn)證該框架能夠適應(yīng)不同程度的資源競爭場景，實(shí)驗(yàn)調(diào)整任務(wù)提交的時(shí)間間隔，使得測試環(huán)境分別處于低資源競爭(平均負(fù)載小于40%)、中資源競爭(平均負(fù)載大于40%小于70%)和高資源負(fù)載(平均負(fù)載大于70%)，用戶按照一定的時(shí)間間隔向上述異構(gòu)系統(tǒng)提交任務(wù)。用戶在3種場景下提交任務(wù)間隔為5 min，1 min和10 s。

對比方法選擇主流的兩個(gè)OpenCL調(diào)度框架：最佳匹配度調(diào)度框架；MultiCL框架。

(1)最佳匹配度調(diào)度框架(MDS)：根據(jù)OpenCL內(nèi)核代碼特征和設(shè)備匹配程度進(jìn)行任務(wù)調(diào)度。

(2)MultiCL框架：基于OpenCL運(yùn)行時(shí)特征實(shí)現(xiàn)自動(dòng)化命令隊(duì)列調(diào)度。

上述兩個(gè)調(diào)度框架是除開發(fā)人員手動(dòng)調(diào)度外，較為常見且高效的調(diào)度框架，其中以最佳匹配調(diào)度框架作為基準(zhǔn)，對比實(shí)驗(yàn)結(jié)果。

6.2 評價(jià)指標(biāo)

為了評估本文所提出的框架，實(shí)驗(yàn)使用了兩個(gè)性能指標(biāo)：系統(tǒng)中任務(wù)執(zhí)行總時(shí)間和負(fù)載平衡度。這兩個(gè)指標(biāo)已被廣泛用于評估多任務(wù)環(huán)境中調(diào)度方法的性能。該框架的目標(biāo)是優(yōu)化任務(wù)執(zhí)行總時(shí)間，這通常會(huì)導(dǎo)致系統(tǒng)的負(fù)載均衡。這兩個(gè)指標(biāo)的定義如下。

任務(wù)執(zhí)行總時(shí)間由系統(tǒng)中最后的任務(wù)完成時(shí)間減去任務(wù)開始時(shí)間表示，這是調(diào)度方法性能的最直接表示，體現(xiàn)了此調(diào)度方案下的執(zhí)行效率。

負(fù)載平衡度[17]是用來量化系統(tǒng)中設(shè)備的負(fù)載平衡程度。它可以定義如下

其中，Vlb代表系統(tǒng)的平均負(fù)載。m代表設(shè)備的數(shù)量。loadk代表設(shè)備k的負(fù)載不同，該部分負(fù)載不是調(diào)度前的估計(jì)值，而是調(diào)度后通過設(shè)備管理器獲取的實(shí)際負(fù)載值。Vlb數(shù)值越小，說明系統(tǒng)負(fù)載就越均衡。該指標(biāo)通過數(shù)學(xué)的方式，將系統(tǒng)負(fù)載均衡程度量化。

7 結(jié)果及分析

在這一節(jié)中，詳細(xì)介紹了上述實(shí)驗(yàn)結(jié)果，并對實(shí)驗(yàn)結(jié)果進(jìn)行了分析，說明本文所提出調(diào)度框架在不同資源競爭環(huán)境下的表現(xiàn)。

實(shí)驗(yàn)將不同數(shù)據(jù)規(guī)模的Parboil OpenCL基準(zhǔn)套件和Ploybench基準(zhǔn)套件程序作為任務(wù)按照不同的時(shí)間間隔提交到在第6節(jié)所敘述的兩個(gè)異構(gòu)系統(tǒng)上，統(tǒng)計(jì)上述兩個(gè)系統(tǒng)的任務(wù)執(zhí)行總時(shí)間和系統(tǒng)負(fù)載均衡程度，為了直觀對比3個(gè)調(diào)度框架的性能，將得到的上述指標(biāo)均比上基準(zhǔn)框架(即最佳匹配度調(diào)度框架)，得到數(shù)據(jù)如圖7和圖8所示。

圖7 不同資源競爭程度下任務(wù)執(zhí)行總時(shí)間

圖8 不同資源競爭程度下系統(tǒng)負(fù)載均衡度

實(shí)驗(yàn)結(jié)果顯示在圖7和圖8中。圖7顯示了3種程度的資源競爭場景下3種調(diào)度方案的總?cè)蝿?wù)完成時(shí)間，圖8顯示了3種負(fù)載情況下3種調(diào)度方案的系統(tǒng)負(fù)載平衡度。本文提出的框架在低資源競爭情況下，相比于MDS算法，任務(wù)執(zhí)行時(shí)間幾乎持平，僅延遲了1%，系統(tǒng)負(fù)載均衡度方面較好，約4%提升；相比于MultiCL任務(wù)執(zhí)行時(shí)間有明顯優(yōu)勢，縮短了約13%，負(fù)載均衡度提升約2%。中資源競爭場景下，相比于MDS算法，任務(wù)執(zhí)行時(shí)間縮短19%，負(fù)載均衡度指標(biāo)提升20%；相比于MultiCL任務(wù)執(zhí)行時(shí)間提升約10%，負(fù)載均衡度指標(biāo)提升約9%。高資源競爭場景下，本文提出的框架表現(xiàn)出良好性能，相比于MDS算法，任務(wù)執(zhí)行時(shí)間縮短了約27%，系統(tǒng)負(fù)載均衡度指標(biāo)提升約29%；相比于MultiCL框架，任務(wù)執(zhí)行效率提升約16%，系統(tǒng)負(fù)載均衡度指標(biāo)提升約12%。本文提出的框架在低資源競爭情況下與MDS算法性能幾乎持平，略高于MultiCL框架，在中高資源競爭下，性能明顯高于MDS算法和MultiCL，符合預(yù)期。

除此之外為了驗(yàn)證該調(diào)度框架滿足OpenCL多任務(wù)調(diào)度的實(shí)時(shí)性要求，針對上述實(shí)驗(yàn)在兩個(gè)系統(tǒng)中所執(zhí)行的Parboil OpenCL基準(zhǔn)套件和Ploybench基準(zhǔn)套件程序，統(tǒng)計(jì)各基準(zhǔn)程序在兩個(gè)CPU-GPU系統(tǒng)中數(shù)據(jù)傳輸，OpenCL內(nèi)核計(jì)算以及調(diào)度所產(chǎn)生的時(shí)間占比，如圖9所示。

圖9 數(shù)據(jù)傳輸、調(diào)度系統(tǒng)和任務(wù)執(zhí)行時(shí)間時(shí)間占比

從圖9可以看出，針對Parboil OpenCL基準(zhǔn)套件中的BFS、Cutup、Sgemm和Spmv程序以及Ploybench基準(zhǔn)套件中的ATAX、BICG、CORR、GESUMMV和SYRK程序，本文提出的調(diào)度框架在調(diào)度階段耗時(shí)僅占有計(jì)算的0.4%～2.1%，該時(shí)間僅為調(diào)度模塊的計(jì)算時(shí)間加上動(dòng)態(tài)特征提取帶來的時(shí)間開銷，靜態(tài)特征提取可在程序初始化階段完成，從圖中可以看出，該調(diào)度框架調(diào)度耗時(shí)與計(jì)算時(shí)間相比幾乎可以忽略，滿足OpenCL運(yùn)行時(shí)的實(shí)時(shí)性要求。

其次對比圖7和圖8，本文所提出的調(diào)度框架所引入的額外開銷遠(yuǎn)小于本文框架所帶來的性能提升，也充分驗(yàn)證了該框架具有良好的實(shí)際運(yùn)用價(jià)值。

結(jié)合上述，在現(xiàn)在主流的兩類CPU+GPU的異構(gòu)系統(tǒng)中，本文所提出的基于資源爭用的調(diào)度框架在不同程度的資源競爭場景下均表現(xiàn)出良好性能，在任務(wù)總執(zhí)行時(shí)間和系統(tǒng)負(fù)載均衡度兩個(gè)指標(biāo)持平或優(yōu)于MDS和MultiCL，尤其是在中高資源競爭場景下，該框架表現(xiàn)出良好的性能優(yōu)勢，同時(shí)也滿足了OpenCL運(yùn)行時(shí)的實(shí)時(shí)性要求。

8 結(jié)束語

本文提出了一個(gè)基于CPU-GPU異構(gòu)平臺上資源爭用的自適應(yīng)、智能化OpenCL多任務(wù)調(diào)度框架。該框架使用OpenCL內(nèi)核和設(shè)備的靜態(tài)和動(dòng)態(tài)特性來分析任務(wù)，為任務(wù)調(diào)度提供良好的數(shù)據(jù)支持。并提出了適用于CPU-GPU異構(gòu)系統(tǒng)的OpenCL數(shù)據(jù)傳輸開銷量化公式。最后通過內(nèi)核并行度估計(jì)內(nèi)核調(diào)度后的設(shè)備負(fù)載變化，結(jié)合內(nèi)核執(zhí)行時(shí)間，在盡可能滿足系統(tǒng)負(fù)載均衡的同時(shí)，保障單個(gè)任務(wù)的執(zhí)行效率。實(shí)驗(yàn)驗(yàn)證在存在中高程度的任務(wù)間競爭環(huán)境下，與其它常見的方法相比，它展現(xiàn)出明顯的性能改進(jìn)。