孫 喬 ,孫家昶 ,馬文靜,2 ,趙玉文,3
1(中國科學(xué)院 軟件研究所 并行軟件與計(jì)算科學(xué)實(shí)驗(yàn)室,北京 100190)
2(計(jì)算機(jī)科學(xué)國家重點(diǎn)實(shí)驗(yàn)室(中國科學(xué)院 軟件研究所),北京 100190)
3(中國科學(xué)院大學(xué),北京 100049)
HPL(high performance Linpack)[1]是一套被廣泛用于測量計(jì)算機(jī)實(shí)際峰值計(jì)算性能的基準(zhǔn)測試程序(benchmark).以其實(shí)際運(yùn)行性能為標(biāo)準(zhǔn),國際超級(jí)計(jì)算機(jī)性能排行榜TOP-500[2]每年會(huì)對眾多超算進(jìn)行性能排名.例如,2019 年,來自美國的超算“Summit”[3]以實(shí)測HPL 148.6 PFLOPS 雙精度浮點(diǎn)性能位居TOP-500 榜首,而來自中國的神威-太湖之光則以93.0 PFLOPS 位居第三.TOP-500 排行榜是衡量全世界超級(jí)計(jì)算機(jī)發(fā)展的重要指標(biāo),而其核心測試程序HPL 的性能優(yōu)化問題歷來是各個(gè)超算廠商乃至各個(gè)國家發(fā)展高性能計(jì)算事業(yè)所關(guān)注的重點(diǎn).在不斷提高HPL 運(yùn)行效率的過程中,程序的性能表現(xiàn)也為計(jì)算機(jī)系統(tǒng)及其基礎(chǔ)軟件的開發(fā)者提供有效的反饋信息,能夠有效促進(jìn)計(jì)算機(jī)系統(tǒng)的向前發(fā)展.
由于眾核協(xié)處理器(如GPGPU)的普及,目前高性能計(jì)算機(jī)一般采用多路(socket)多核CPU+眾核協(xié)處理器架構(gòu),如在2019 年TOP-500 榜單中名列前茅的Summit、Sierra 及天河2 號(hào)等.CPU 和協(xié)處理器往往采用不同的體系結(jié)構(gòu)及指令集,這樣的計(jì)算機(jī)架構(gòu)被稱為異構(gòu)計(jì)算機(jī)架構(gòu).在這樣的系統(tǒng)中,傳統(tǒng)多核CPU 負(fù)責(zé)執(zhí)行程序的邏輯密集部分,眾核協(xié)處理器則高效地處理程序中計(jì)算密集的部分.由于協(xié)處理器的高性能主要依賴于大量輕量級(jí)核心提供的并行處理能力,因此可大幅度提高計(jì)算機(jī)系統(tǒng)整體的計(jì)算功耗比.鑒于異構(gòu)眾核架構(gòu)諸多優(yōu)勢,其如今已在事實(shí)上成為了當(dāng)今高性能計(jì)算機(jī)建設(shè)的主流解決方案.
圖1 展示了目前典型的異構(gòu)眾核架構(gòu),從總體上來說,該架構(gòu)可以簡單地區(qū)分為Host端和Device端.Host端采用的CPU 具有多個(gè)物理上分開的Socket,而每個(gè)Socket 中有若干物理核心.這些核心是常規(guī)CPU 核心,能夠有效處理程序中復(fù)雜的邏輯判斷部分,因此程序的主進(jìn)程運(yùn)行在這些核心上.從內(nèi)存層次結(jié)構(gòu)上看,當(dāng)今多路多核CPU 一般具有多級(jí)數(shù)據(jù)和指令緩存.如圖1 所示,每個(gè)CPU 核心具有獨(dú)立的一級(jí)緩存(L1-cache),而處于同一Socket 的若干CPU 核心共享二級(jí)Cache(L2-cache),可有效加速多個(gè)CPU 核心間共享數(shù)據(jù)或指令的訪問.而作為CPU 與內(nèi)存之間的橋梁,三級(jí)Cache(L3-cache)用來提高CPU 整體的訪存速度.從圖1 中還可以看到,異構(gòu)眾核系統(tǒng)的內(nèi)存和CPU 的各個(gè)Socket 一樣也是物理上獨(dú)立的,每個(gè)Socket 都有與自己鄰近的一塊物理內(nèi)存,該Socket 上的CPU 核心能夠以較低的延遲訪問近端內(nèi)存,但若訪問遠(yuǎn)端內(nèi)存則延遲大幅度提高.各個(gè)Socket直接由高速網(wǎng)絡(luò)互聯(lián),并在硬件上實(shí)現(xiàn)了訪存一致性協(xié)議,形成cc-NUMA(cache coherent non-uniform memory access)結(jié)構(gòu),使得各個(gè)CPU 核心能在邏輯上共享一致的內(nèi)存空間.值得注意的是,緩存一致性協(xié)議及遠(yuǎn)端內(nèi)存訪問會(huì)帶來較大的開銷,一種比較通用的方法是將各個(gè)進(jìn)程分布在不同的Socket 上使得各個(gè)進(jìn)程僅利用與該Socket 毗鄰的資源.
目前Device端可以配備多個(gè)協(xié)處理器設(shè)備.這些協(xié)處理器相對于CPU 來說具有很高的計(jì)算能力.這樣強(qiáng)大的計(jì)算能力一般是通過大規(guī)模并行計(jì)算實(shí)現(xiàn).以當(dāng)今主流的GPGPU 為例,一塊GPGPU 卡中包含了眾多流處理器,這些處理器結(jié)構(gòu)相對簡單而不適合處理邏輯復(fù)雜的代碼,但這些流處理器在硬件上整合了大量的向量計(jì)算部件并實(shí)現(xiàn)了高效的線程切換機(jī)制.這樣,一個(gè)流處理器能夠高效地調(diào)度大量線程予以向量化并行執(zhí)行.協(xié)處理器擁有獨(dú)立的內(nèi)存空間,一般通過PCI-e 總線與Host端的內(nèi)存進(jìn)行數(shù)據(jù)交換.
雖然上述異構(gòu)架構(gòu)較為普及,但以往對 大規(guī)模超級(jí)計(jì)算機(jī)上HPL 測試程序的優(yōu)化工作的開展大多基于進(jìn)程與協(xié)處理器一一對應(yīng)這一前提[4?6].這種方案易于優(yōu)化,也可避免緩存一致性協(xié)議及訪問遠(yuǎn)端內(nèi)存帶來的開銷.但在HPL 程序的實(shí)際執(zhí)行過程中,這種方案將不可避免地導(dǎo)致大量處理器空閑,并增加結(jié)點(diǎn)內(nèi)進(jìn)程間通信開銷.在本文中,我們面向高度異構(gòu)架構(gòu)提出一套新型HPL 測試程序Hetero-HPL,突破以往進(jìn)程與協(xié)處理必須一一對應(yīng)這一限制,使用進(jìn)程內(nèi)多協(xié)處理級(jí)并行方案,進(jìn)而研究基于此方案的性能優(yōu)化方法,在執(zhí)行過程中更充分地利用各種硬件資源.
Fig.1 Typical architecture of multi-device heterogeneous platform圖1 典型多設(shè)備異構(gòu)平臺(tái)架構(gòu)
本節(jié)僅簡要介紹HPL 程序執(zhí)行過程中與本文工作相關(guān)的大致流程,關(guān)于各種算法細(xì)節(jié)可以參考[3,7?9]等,在此不再贅述.HPL 測試程序以多進(jìn)程分布式的方式求解線性方程組Ax=b.矩陣A以二維循環(huán)塊卷簾(block cyclic)的方式分布在二維矩形進(jìn)程拓?fù)渖?由于進(jìn)程拓?fù)湓O(shè)置具有自由性,而HPL 測試常?;谡叫芜M(jìn)程拓?fù)浣Y(jié)構(gòu)而展開,因此本文僅討論典型的正方形進(jìn)程拓?fù)湎碌腍PL 分解算法,但本文工作也可用于非正方形進(jìn)程拓?fù)浣Y(jié)構(gòu)的HPL 測試.
HPL 程序首先采用部分選主元(patial pivoting)的方式對隨機(jī)矩陣A進(jìn)行LU 分解,之后進(jìn)行回代求解向量b.由于其絕大部分計(jì)算量集中在對矩陣A的LU 分解部分,對HPL算法的性能優(yōu)化工作主要圍繞該部分展開.對矩陣A的LU 分解操作從邏輯上可以分為Panel 分解及Update(尾子矩陣更新)兩個(gè)部分.圖2 展示了HPL 程序在3×3 進(jìn)程拓?fù)湎碌拇篌w執(zhí)行流程.
在圖2 中我們可以看到,對矩陣A的LU 分解過程以由多個(gè)迭代步驟完成.在每次迭代過程中,首先處于某一特定列(簡稱P-Fact 列)的所有進(jìn)程協(xié)作完成Panel 的分解.Panel 分解完成對當(dāng)前瘦高子矩陣(panel)的部分選主元過程的LU 分解操作.從具體算法上看,Panel 分解可選擇向左或向右看(left/right looking)或Crout LU 分解算法.這三者計(jì)算量大致相等,具體的選擇可根據(jù)實(shí)際運(yùn)行的效率決定.P-Fact 列的進(jìn)程在Panel 分解執(zhí)行之后,通過數(shù)據(jù)傳輸,將產(chǎn)生的行交換信息(dpiv),Panel 分解的結(jié)果矩陣(L1 和L2)分享給同一進(jìn)程行中的其他進(jìn)程列,并開始接下來的Update 操作.在此值得一提的是,在Panel 分解過程所涉及的計(jì)算從形式上說具有邏輯復(fù)雜,小規(guī)模反復(fù)執(zhí)行等特點(diǎn),并行度較小.因此線程啟停開銷,函數(shù)調(diào)用,數(shù)據(jù)傳輸開銷將嚴(yán)重制約Panel 分解過程的效率.因此其不適合采用Device端加速設(shè)備執(zhí)行.
Fig.2 One iteration of HPL algorithm圖2 HPL算法單次迭代
在Panel 分解執(zhí)行完畢之后,所有列的進(jìn)程開始執(zhí)行Update 過程.在該過程中擁有矩陣U(或其某一部分)的進(jìn)程行我們稱為U行進(jìn)程.這些進(jìn)程將U中待交換的矩陣行集合后配合其他行進(jìn)程完成矩陣對應(yīng)列的分布式行交換過程,其結(jié)果是每一進(jìn)程都擁有自身矩陣對應(yīng)所需的U矩陣.之后,參與Update 操作的所有進(jìn)程分別利用得到的L1 矩陣對交換后的U矩陣進(jìn)行dtrsm(三角矩陣求解)更新,并利用得到的L2 矩陣和矩陣U對所屬自身的尾子矩陣調(diào)用dgemm(矩陣乘法)完成更新.
不論進(jìn)程與CPU 以怎樣的方式對應(yīng),HPL算法中占據(jù)絕大部分計(jì)算量的尾子矩陣更新操作都能完全利用所有協(xié)處理器完成.在該過程通過協(xié)處理進(jìn)行充分加速之后,其余的零散計(jì)算的資源使用率將成為性能瓶頸.其中典型的有Panel 分解操作及處于Update 階段的分布式行交換操作.從算法流程上,在HPL 的每一次迭代步驟中,只有特定P-Fact 列進(jìn)程完成本次迭代所需的Panel 分解操作,同時(shí)也只有U行進(jìn)程參與矩陣U的廣播.因此不同的進(jìn)程與處理器的映射關(guān)系會(huì)導(dǎo)致不同的資源使用情況.圖3 展示了一個(gè)由4 個(gè)實(shí)驗(yàn)節(jié)點(diǎn)(具體參數(shù)介紹見第5.1 節(jié))組成的分布式環(huán)境.圖3 左側(cè)展示了進(jìn)程與Socket 一一對應(yīng)的情況.由于每一個(gè)Socket 僅管理8 個(gè)CPU 核心和一個(gè)協(xié)處理設(shè)備.因此在P-Fact 過程中只有共計(jì)8×4=32 個(gè)CPU 核心參與Panel 分解運(yùn)算,而在Update 階段的行交換過程中,僅有4 個(gè)協(xié)處理器完成對U矩陣的打包并由對應(yīng)的4 道PCI-e 總線進(jìn)行傳輸.若采用圖3 右側(cè)進(jìn)程與節(jié)點(diǎn)(node)一一對應(yīng)的方式執(zhí)行HPL 程序,每個(gè)進(jìn)程管控4 個(gè)協(xié)處理器設(shè)備,則在Panel 分解部分將有8×4×2=64 個(gè)CPU 核心參與計(jì)算,而在Update 階段的行交換過程中會(huì)有8 個(gè)協(xié)處理器及其PCI-e總線參與.隨著協(xié)處理器運(yùn)算能力的進(jìn)一步增長,占絕大部分計(jì)算量的BLAS 3 級(jí)函數(shù)能夠很快完成,而諸如Panel 分解,數(shù)據(jù)打包等必要步驟的運(yùn)行時(shí)間比重將進(jìn)一步加大,因此應(yīng)在這些步驟中應(yīng)盡可能地充分利用各種硬件資源.
Fig.3 Different mappings between processes and nodes圖3 進(jìn)程與節(jié)點(diǎn)的不同對應(yīng)關(guān)系
為了提高HPL 各個(gè)階段的資源利用率.本文提出Hetero-HPL 方案.總體上,Hetero-HPL 中每一個(gè)進(jìn)程能夠管理任意數(shù)量的協(xié)處理器,在大幅度提高上述關(guān)鍵計(jì)算步驟的資源利用率的前提下,以協(xié)處理器間高度負(fù)載均衡的方式完成HPL 計(jì)算.Hetero-HPL 對原始HPL算法做出的改動(dòng)可歸納為數(shù)據(jù)映射及操作映射兩個(gè)方面,分別對應(yīng)于如圖4 所示的MD_Mapping 框架及MD_Primitive算法庫.它們將在本節(jié)中分別予以介紹.
Fig.4 Architecture of Hetero-HPL圖4 Hetero-HPL 總體結(jié)構(gòu)
在數(shù)據(jù)映射部分,Hetero-HPL 要解決如下3 個(gè)問題:(1) 確保Update 中BLAS 3 函數(shù)完全由協(xié)處理器(組)完成,以接近計(jì)算平臺(tái)的理論性能峰值;(2) 各個(gè)協(xié)處理器間計(jì)算相互獨(dú)立,以避免冗余的跨協(xié)處理器的數(shù)據(jù)交換及相互依賴;(3) 在每一次迭代過程中,各個(gè)協(xié)處理器間應(yīng)保持負(fù)載均衡.為同時(shí)解決這3 個(gè)問題,我們?yōu)槌砻芫仃囋趨f(xié)處理器間進(jìn)行數(shù)據(jù)劃分提供一套框架,名為Matrix-Device_Mapping(簡稱MD_Mapping),提供高層接口便于開發(fā)者在邏輯上訪問任意子矩陣,屏蔽了數(shù)據(jù)物理分布細(xì)節(jié).
如圖5 所示,在每一個(gè)進(jìn)程中MD_Mapping 框架將HPL 程序生成的初始偽隨機(jī)矩陣劃分到各個(gè)協(xié)處理器.由于在Update 階段,同一進(jìn)程上的各個(gè)矩陣列間的操作是獨(dú)立的,因此最自然的數(shù)據(jù)劃分策略即為按矩陣列進(jìn)行劃分,以NB為寬度形成若干個(gè)列塊.由于計(jì)算過程中,尾子矩陣的規(guī)模逐漸變小,若按照列方向線性劃分并指派到各個(gè)協(xié)處理,則會(huì)導(dǎo)致協(xié)處理負(fù)載不均衡問題.因此,我們在MD_Mapping庫中采用按列塊循環(huán)卷簾的方式將諸多列塊平均分配到各個(gè)協(xié)處理上.MD_Mapping庫以描述符的方式選取原始矩陣的任意子矩陣,即便這些子矩陣在物理上分布于不同的協(xié)處理器.運(yùn)算圍繞相關(guān)子矩陣實(shí)現(xiàn).值得注意的是,假如我們對各個(gè)協(xié)處理器從0 開始依次進(jìn)行編號(hào),并采用MD_Mapping 中使用的列塊循環(huán)卷簾數(shù)據(jù)排布方式,在同一列的不同進(jìn)程上,原始矩陣中同一列元素所在的協(xié)處理器編號(hào)是相等的.這便于今后采用協(xié)處理間直接通信機(jī)制來優(yōu)化Hetero-HPL程序性能.
Fig.5 Matrix partition based on MD_Mapping framework圖5 基于MD_Mapping 框架的矩陣劃分
在Update 階段,HPL算法主要涉及3 種操作:(1) (分布式)行交換;(2) 上三角矩陣更新dtrsm;(3) 尾子矩陣乘更新dgemm.而在具有多設(shè)備的異構(gòu)眾核平臺(tái)上,數(shù)據(jù)在Host 及Device 之間數(shù)據(jù)一致性也需要通過數(shù)據(jù)傳遞來實(shí)現(xiàn).因此,我們在 MD_Mapping 框架上實(shí)現(xiàn)了 MD_Primitive庫.MD_Primitive 層以MD_Mapping 提供的子矩陣描述符為操作對象,調(diào)用所有相關(guān)協(xié)處理器協(xié)同(并行)完成施加于目標(biāo)子矩陣的操作,如數(shù)據(jù)傳遞,三角矩陣更新和矩陣乘更新等.另外,MD_Primitive 中的函數(shù)調(diào)用接口皆為異步接口,可以方便實(shí)施多操作重疊執(zhí)行.在具備MD_Mapping 框架及MD_Primitive庫之后,Hetero-HPL 的大致程序結(jié)構(gòu)如圖6 所示,其中,綠色字體代表同步調(diào)用,紅色字體代表異步調(diào)用.
在整體算法開始之前,MD_Mapping 已經(jīng)完成了對初始系統(tǒng)Ax=b的映射,生成映射實(shí)例MatrixMapping.由于Hetero-HPL 主要對HPL算法的Update 階段進(jìn)行了重構(gòu),因此我們圍繞Update 階段進(jìn)行闡述,其偽代碼如圖6 左側(cè)所示.通過MatrixMapping 實(shí)例,程序獲取兩個(gè)子矩陣描述符(第3 行~第6 行),分別為 NextPanel(下一 Panel)及 TrailingMatrix(尾子矩陣).這兩個(gè)子矩陣實(shí)例的實(shí)際數(shù)據(jù)分布細(xì)節(jié)被MD_Mapping 框架屏蔽.MD_Mapping 為每個(gè)設(shè)備預(yù)留了數(shù)據(jù)緩存L(可進(jìn)一步劃分為L1 和L2)用來放置分解完畢的Panel 數(shù)據(jù).各個(gè)子矩陣實(shí)例可按需要分配屬于自身的Device端數(shù)據(jù)緩存U.數(shù)據(jù)緩存L及U將在接下來的步驟中使用,包括行交換(第11 行及第18 行),上三角矩陣更新(第12 行及第19 行)和矩陣乘更新(第13 行及第20 行).這些步驟由MD_Primitive庫中函數(shù)實(shí)現(xiàn).我們將施加于NextPanel 的所有運(yùn)算完成之后,開啟異步傳輸(第15 行),從對應(yīng)的設(shè)備上將NextPanel 的數(shù)據(jù)拷貝回Host端內(nèi)存,進(jìn)而完成下一次Panel 分解操作.與此同時(shí),對TrailingMatrix 的上三角矩陣更新及矩陣乘更新可以通過異步接口與下一次Panel 分解并行執(zhí)行,如圖6 右側(cè)所示.
Fig.6 Pesudo-code of Hetero-HPL based on MD_Mapping and MD_Primitive圖6 基于MD_Mapping 及MD_Primitive 實(shí)現(xiàn)的Hetero-HPL 偽代碼
在現(xiàn)在主流異構(gòu)平臺(tái)上,Host端內(nèi)存和Device端協(xié)處理器內(nèi)存的數(shù)據(jù)交換主要通過PCI-e 總線完成.若要盡可能充分地利用PCI-e 總線的帶寬(約32GB/s,全雙工)則需要在Host端開辟鎖頁內(nèi)存(pinned memory).鎖頁內(nèi)存的最大特點(diǎn)是其不會(huì)被操作系統(tǒng)換出到硬盤交換區(qū),以便于設(shè)備端建立物理地址映射,因此對協(xié)處理器來說可以通過DMA 機(jī)制高速訪問.相比于以常規(guī)方式申請的內(nèi)存空間來說,鎖頁內(nèi)存能夠擁有2~3 倍的訪問速率.然而,鎖頁內(nèi)存一般為連續(xù)的物理內(nèi)存空間,其申請受到單一NUMA 節(jié)點(diǎn)上內(nèi)存大小的限制.為確保數(shù)據(jù)在Host端及Device端對應(yīng),在擁有若干協(xié)處理平臺(tái)上,單次申請的鎖頁內(nèi)存容量很可能遠(yuǎn)小于所有設(shè)備內(nèi)存的總和[10].因此,面向 Hetero-HPL,我們對原始矩陣建立軟件緩存,采用若干鎖頁內(nèi)存來替代非鎖頁內(nèi)存.
如圖7 所示,以目標(biāo)平臺(tái)為例,假設(shè)原始矩陣大小為64GB,在Hetero-HPL 中,我們開辟兩片(或多片)鎖頁內(nèi)存區(qū)域(大小都為32GB),然后采用同樣的偽隨機(jī)數(shù)生成算法直接初始化這兩片內(nèi)存區(qū)域.之后,在LU 分解的過程中,Hetero-HPL 直接與這兩片鎖頁內(nèi)存完成多次矩陣Panel 的相互交換.值得一提的是,原始的64GB非鎖頁內(nèi)存區(qū)域在Hetero-HPL 執(zhí)行過程中并不需要真實(shí)存在,因此Hetero-HPL 并不會(huì)帶來冗余內(nèi)存消耗.通過簡單的地址變換,Hetero-HPL 也不會(huì)通過大量冗余操作來進(jìn)行數(shù)據(jù)傳輸.在Hetero-HPL 執(zhí)行完成之后,我們獲取解向量b并釋放掉所有鎖頁內(nèi)存.之后再由驗(yàn)證程序在64GB 非鎖頁內(nèi)存中重建整個(gè)線性系統(tǒng),進(jìn)而完成結(jié)果驗(yàn)證.
Fig.7 Original un-pinned memory is replaced by two pinned memory regions圖7 采用兩片鎖頁內(nèi)存區(qū)域替代原始非鎖頁內(nèi)存
Fig.8 Merge of the same operation on each co-processor圖8 協(xié)處理器上同種操作的歸并
由于我們采用了按列塊循環(huán)卷簾的方式在各個(gè)協(xié)處理器上分配矩陣數(shù)據(jù),而每一列塊的列數(shù)僅為NB(通常為128,256,512 等),因此施加在某一列塊上的操作(如矩陣乘dgemm 函數(shù))可能會(huì)由于其數(shù)據(jù)規(guī)模過小而無法充分發(fā)揮協(xié)處理器的大規(guī)模并行計(jì)算能力.針對HPL算法程序,由于各個(gè)列塊間計(jì)算相互獨(dú)立,我們可以利用矩陣不同列間計(jì)算的結(jié)合律,讓位于同一協(xié)處理的所有列塊同時(shí)執(zhí)行相同操作,即便這些列塊在邏輯上并不相連.如圖8 虛線框所示的子矩陣,其由多個(gè)列塊構(gòu)成.在每一個(gè)協(xié)處理器上,我們只需調(diào)用一次dgemm 函數(shù)就可以完成該協(xié)處理器上所有列塊的更新.類似地,同一進(jìn)程中的行交換,dtrsm 等操作也可以進(jìn)行歸并,故不再贅述.
Panel 分解過程的各個(gè)步驟由于計(jì)算規(guī)模小,調(diào)用頻繁而不利于使用協(xié)處理器進(jìn)行加速.因此,在當(dāng)前的Hetero-HPL 版本中,我們將Panel 分解放置在CPU端執(zhí)行.如前文所述,相對于進(jìn)程與協(xié)處理一一對應(yīng)的方案而言,在Hetero-HPL 中Panel 分解操作將有條件利用更多CPU 核心來完成計(jì)算.在HPL算法中下一次迭代步的Panel 分解可以和當(dāng)前次迭代的尾子矩陣dgemm 更新并行執(zhí)行.我們結(jié)合MD_Primitive庫中的異步函數(shù)接口,可以很輕易地完成上述兩個(gè)關(guān)鍵步驟的異步并行執(zhí)行.
由于待分解的矩陣被置于協(xié)處理器內(nèi)存中,因此我們需要手工編寫協(xié)處理器代碼以實(shí)施相應(yīng)運(yùn)算.對于BLAS 函數(shù),我們可以直接調(diào)用RocBLAS庫.而對于諸如行交換,矩陣轉(zhuǎn)置等操作則需要我們手工編寫計(jì)算Kernel 完成.在此過程中,我們一方面要利用協(xié)處理器的大規(guī)模并行能力,另一方面我們也需要利用計(jì)算的可結(jié)合性,盡量在一次Kernel 啟動(dòng)中完成同一協(xié)處理器上所有數(shù)據(jù)的計(jì)算.
Hetero-HPL 面向當(dāng)前主流的多協(xié)處理器架構(gòu)構(gòu)建,因此我們采用一個(gè)多核CPU+多個(gè)GPU 的典型異構(gòu)系統(tǒng)作為實(shí)驗(yàn)平臺(tái).實(shí)驗(yàn)平臺(tái)具有Host端及Device端.Host端采用4 路8 核Intel 指令集架構(gòu).與每路CPU 核心鄰近的內(nèi)存大小為32GB,系統(tǒng)共計(jì)128GB 內(nèi)存空間.Device端為4 個(gè)類GPGPU 設(shè)備,每塊類GPGPU 擁有64 個(gè)流處理器,16GB 設(shè)備內(nèi)存.實(shí)驗(yàn)平臺(tái)Host端支持Posix 標(biāo)準(zhǔn).因此可以采用常用的并行編程模型如MPI、OpenMP 等.而對于Device端的類GPGPU 設(shè)備,實(shí)驗(yàn)平臺(tái)提供基礎(chǔ)并行編程環(huán)境Hip,并擁有開源基礎(chǔ)并行算法庫Rocm[10].類似于NVIDIA 公司推出的通用顯卡計(jì)算編程環(huán)境CUDA 及其加速算法庫CUDA Toolkit[11],實(shí)驗(yàn)平臺(tái)能夠支持手工編寫并編譯適用于Device端運(yùn)行的計(jì)算kernel,還可以直接利用Rocm算法庫中的高性能函數(shù)實(shí)現(xiàn)并優(yōu)化程序.另外,HPL 程序的高效執(zhí)行離不開底層高效執(zhí)行的基礎(chǔ)線性代數(shù)庫 BLAS.在Host端,實(shí)驗(yàn)平臺(tái)采用BLIS[4]數(shù)學(xué)庫,其dgemm 執(zhí)行效率可以高達(dá)CPU 理論峰值性能的98%以上.而在Device端,我們同樣可以利用Rocm算法庫中的RocBLAS 數(shù)學(xué)庫模塊,其dgemm 性能約為單塊協(xié)處理器理論性能的84%以上.
Hetero-HPL 可以支持所有128 倍數(shù)的NB取值.通過實(shí)驗(yàn)我們發(fā)現(xiàn)NB=256 能夠取得較優(yōu)的總體性能.另外在NB=256 時(shí),Device端矩陣乘法效率大約為機(jī)器峰值性能的84%.我們選取31 個(gè)CPU 核心參與Panel 分解計(jì)算,也能獲得較優(yōu)的總體性能.
圖9 展示了Hetero-HPL 在單節(jié)點(diǎn)單進(jìn)程情況下的運(yùn)行效率.隨著矩陣規(guī)模的擴(kuò)大,執(zhí)行效率呈現(xiàn)大幅度上升趨勢.在矩陣階數(shù)達(dá)到88 320(4 個(gè)協(xié)處理器設(shè)備內(nèi)存占用率達(dá)到95.5%)時(shí),Hetero-HPL 的運(yùn)行效率達(dá)到了實(shí)驗(yàn)平臺(tái)峰值性能的76.53%,同時(shí)也達(dá)到了dgemm 性能的91.11%,因此可見Hetero-HPL 在單節(jié)點(diǎn)單進(jìn)程情況下能夠取得較優(yōu)的性能.
Fig.9 Efficiency trend of single process Hetero-HPL with respect to matrix rank圖9 單進(jìn)程Hetero-HPL 執(zhí)行效率隨著矩陣階數(shù)變化趨勢
圖10 展示了Hetero-HPL 在4~256 個(gè)節(jié)點(diǎn)的運(yùn)行性能.實(shí)驗(yàn)中每個(gè)進(jìn)程的Device端內(nèi)存使用量達(dá)到96.0%.我們的工作展示了基于單進(jìn)程控制多協(xié)處理器技術(shù)的 HPL算法在分布式環(huán)境下的測試結(jié)果.但意外的是,Hetero-HPL 雖然在算法層面并沒有引入多余的數(shù)據(jù)傳輸量,但是程序的性能隨著進(jìn)程數(shù)的增加而大幅度降低.由于HPL算法本身具有很好的可擴(kuò)展性,而在實(shí)際測量中我們發(fā)現(xiàn)通信所耗費(fèi)的時(shí)間約為總體計(jì)算時(shí)間的25%~30%,因此我們認(rèn)為通信效率成為制約Hetero-HPL 在分布式環(huán)境下擴(kuò)展性的一個(gè)重要方面.
Fig.10 Scalability of Hetero-HPL on 4~256 nodes圖10 Hetero-HPL 在4~256 個(gè)節(jié)點(diǎn)可擴(kuò)展性
Hetero-HPL 通信開銷表現(xiàn)在3 個(gè)方面.第一,PCI-e 總線利用率不高.以Panel 分解相關(guān)的節(jié)點(diǎn)內(nèi)傳輸為例,由于目前采用NB為列數(shù)按列方向劃分矩陣,使得任意一個(gè)Panel 從Device端拷貝到Host端僅能采用一路PCI-e總線.若使用NB/D(D為設(shè)備數(shù)量)為列數(shù)進(jìn)行矩陣劃分并在設(shè)備間卷簾排布,則可以確保任意一個(gè)Panel 的數(shù)據(jù)均勻分布于所有設(shè)備,上述傳輸可以使用所有PCI-e 總線并行完成.另外第4.2 節(jié)所述的操作歸并技術(shù)亦可在更細(xì)粒度的數(shù)據(jù)劃分方案上使用,可確保設(shè)備端的計(jì)算性能.第二,Panel 分解階段并未實(shí)現(xiàn)計(jì)算通信重疊.我們認(rèn)為能夠利用Panel 分解過程中BLAS 3 級(jí)函數(shù)來掩蓋部分Panel 相關(guān)的數(shù)據(jù)傳輸.第三,進(jìn)程間的MPI 通信效率有待考證.由于Hetero-HPL 不能直接控制底層網(wǎng)絡(luò)資源(如多塊網(wǎng)卡),因此如何配置MPI 使其針對Hetero-HPL發(fā)揮最優(yōu)性能也是一個(gè)值得深入研究的問題.
自從HPL 程序被提出并作為高性能計(jì)算評(píng)測標(biāo)準(zhǔn),對其研究和改進(jìn)及在不同平臺(tái)上的并行方案、優(yōu)化方法及計(jì)算模型研究就未曾中斷過.從早期的Intel Paragon 平臺(tái)上的實(shí)現(xiàn)與測試[12],到現(xiàn)今世界最快的超級(jí)計(jì)算機(jī)上的優(yōu)化與開拓[13],對HPL算法及優(yōu)化的研究一直在影響著計(jì)算機(jī)軟硬件設(shè)計(jì)與發(fā)展.異構(gòu)平臺(tái)上的HPL 一般是主要由速度較快的加速器來完成矩陣更新操作,CPU 負(fù)責(zé)通信及Panel 分解[6,7].Wang 等為GPU+多核CPU平臺(tái)設(shè)計(jì)了分階段動(dòng)態(tài)任務(wù)劃分的方法及軟件流水線,以充分利用計(jì)算和通信資源[8].Heinecke 等人針對帶有MIC 加速卡的平臺(tái),做了細(xì)粒度多層次的任務(wù)劃分,從而實(shí)現(xiàn)對各部件的充分合理使用[9].Gan 等面向HPL 在國產(chǎn)加速器China accelerator 上對dgemm 進(jìn)行了優(yōu)化,并使用靜態(tài)與動(dòng)態(tài)相結(jié)合的調(diào)度方式來協(xié)調(diào)CPU 與加速器之間的工作[3].對多GPU 平臺(tái)上的HPL 研究,陳任之等人工作采用了與本文工作類似的單進(jìn)程控制多協(xié)處理器案[14].但是由于其并沒有將尾子矩陣駐留于Device端,因此數(shù)據(jù)在Host端和Device端的來回傳輸對整體性能產(chǎn)生了負(fù)面影響.相似的方案也被AMD 公司采用,為HPL 中的dgemm 實(shí)現(xiàn)了單進(jìn)程多設(shè)備版本[11].與上述兩個(gè)方案不同的是Hetero-HPL 在多協(xié)處理器環(huán)境中也實(shí)現(xiàn)了全局?jǐn)?shù)據(jù)的駐留,根本上避免了尾子矩陣的搬移.Jia 等人提出了與Hetero-HPL 類似的解決方案,確保了數(shù)據(jù)多設(shè)備端的駐留并采用了按列塊循環(huán)卷簾數(shù)據(jù)結(jié)構(gòu)確保數(shù)據(jù)負(fù)載均衡[6].但值得指出的是,Jia 等人沒有考慮到鎖頁內(nèi)存分配大小限制小于Device端所有設(shè)備內(nèi)存總量這一情況.在如本文所述的平臺(tái)上,該方案只能處理較小階數(shù)的矩陣,因而無法充分反映平臺(tái)性能,因此其單節(jié)點(diǎn)性能僅達(dá)到機(jī)器峰值性能的46.06%.另外,由于其方案采用了激進(jìn)的動(dòng)態(tài)調(diào)度策略,其復(fù)雜性也進(jìn)一步降低了該方案在多進(jìn)程環(huán)境中的可行性.在以上兩方面,本文工作更為深入.
面向當(dāng)今主流的異構(gòu)高性能計(jì)算平臺(tái),本文提出了Hetero-HPL 測試程序.整體上,Hetero-HPL 所依賴的數(shù)據(jù)對協(xié)處理器的映射規(guī)則,并行策略等并不依賴于具體的硬件架構(gòu)及基礎(chǔ)軟件,因此有能力在現(xiàn)有多種主流眾核架構(gòu)上進(jìn)行部署.Hetero-HPL 還從根本上突破了進(jìn)程數(shù)量與協(xié)處理器數(shù)量必須相等的限制,更進(jìn)一步提高了其實(shí)用性.在執(zhí)行過程中,單個(gè)進(jìn)程攜帶多個(gè)協(xié)處理器的配置有利于在Panel 分解和分布式行交換過程中利用更多了的計(jì)算資源,有利于執(zhí)行效率的提高.Hetero-HPL 基于MD_Mapping 框架和MD_Primitive庫,使占主要計(jì)算量的尾子矩陣更新步驟完全利用多個(gè)協(xié)處理器提供的大規(guī)模并行計(jì)算能力,同時(shí)也避免了同一進(jìn)程中多個(gè)協(xié)處理器間相互數(shù)據(jù)交換并確保各協(xié)處理器間計(jì)算量的均衡.面向多設(shè)備異構(gòu)平臺(tái),我們突破了鎖頁內(nèi)存分配限制,利用多塊鎖頁內(nèi)存在邏輯上替代原始非鎖頁內(nèi)存,使Hetero-HPL Device端與Host端的內(nèi)存交換僅發(fā)生在鎖頁內(nèi)存中,確保了執(zhí)行的高效.在本文中,我們面向多設(shè)備異構(gòu)系統(tǒng)嘗試了一些基礎(chǔ)但必要的優(yōu)化手段,其中包括Panel 分解與尾子矩陣dgemm 更新的異步并行,同一協(xié)處理器上相同計(jì)算的歸并及行交換相關(guān)操作在協(xié)處理器端的并行化實(shí)現(xiàn).實(shí)驗(yàn)結(jié)果表明,在單節(jié)點(diǎn)條件下Hetero-HPL 達(dá)到了實(shí)驗(yàn)平臺(tái)峰值性能的76.53%(dgemm實(shí)測性能的91.1%).Hetero-HPL 還展示了基于單進(jìn)程控制多設(shè)備技術(shù)的HPL算法在多節(jié)點(diǎn)分布式環(huán)境下的可行性.但目前由于網(wǎng)絡(luò)通信及PCI-e 數(shù)據(jù)交換的開銷比例過大,程序執(zhí)行效率還需進(jìn)一步提高,這是我們將要深入研究的一個(gè)重要方面.
基于Hetero-HPL,我們未來將主要開展兩方面的工作.一方面,進(jìn)一步在目標(biāo)平臺(tái)上深入優(yōu)化Hetero-HPL程序.其中包括深入挖掘Hetero-HPL 程序中的并行性,使更多關(guān)鍵步驟,如Panel 在Host端及Device端的來回傳遞、跨進(jìn)程的廣播和分布式行交換等得以并行執(zhí)行;在此基礎(chǔ)上,分析各個(gè)步驟在各次迭代中的時(shí)間占比,基于動(dòng)態(tài)信息反饋安排不同的異步并行方案.另一方面,我們可以在若干不同的平臺(tái)上實(shí)現(xiàn)Hetero-HPL,梳理制約Hetero-HPL 性能的一般性因素,為Hetero-HPL 的性能表現(xiàn)建立數(shù)學(xué)模型.