孫 喬 ,孫家昶 ,馬文靜,2 ,趙玉文,3

1(中國科學院 軟件研究所 并行軟件與計算科學實驗室,北京 100190)

2(計算機科學國家重點實驗室(中國科學院 軟件研究所),北京 100190)

3(中國科學院大學,北京 100049)

1 HPL 基準測試及主流異構并行架構

HPL(high performance Linpack)[1]是一套被廣泛用于測量計算機實際峰值計算性能的基準測試程序(benchmark).以其實際運行性能為標準,國際超級計算機性能排行榜TOP-500[2]每年會對眾多超算進行性能排名.例如,2019 年,來自美國的超算“Summit”[3]以實測HPL 148.6 PFLOPS 雙精度浮點性能位居TOP-500 榜首,而來自中國的神威-太湖之光則以93.0 PFLOPS 位居第三.TOP-500 排行榜是衡量全世界超級計算機發(fā)展的重要指標,而其核心測試程序HPL 的性能優(yōu)化問題歷來是各個超算廠商乃至各個國家發(fā)展高性能計算事業(yè)所關注的重點.在不斷提高HPL 運行效率的過程中,程序的性能表現(xiàn)也為計算機系統(tǒng)及其基礎軟件的開發(fā)者提供有效的反饋信息,能夠有效促進計算機系統(tǒng)的向前發(fā)展.

由于眾核協(xié)處理器(如GPGPU)的普及,目前高性能計算機一般采用多路(socket)多核CPU+眾核協(xié)處理器架構,如在2019 年TOP-500 榜單中名列前茅的Summit、Sierra 及天河2 號等.CPU 和協(xié)處理器往往采用不同的體系結構及指令集,這樣的計算機架構被稱為異構計算機架構.在這樣的系統(tǒng)中,傳統(tǒng)多核CPU 負責執(zhí)行程序的邏輯密集部分,眾核協(xié)處理器則高效地處理程序中計算密集的部分.由于協(xié)處理器的高性能主要依賴于大量輕量級核心提供的并行處理能力,因此可大幅度提高計算機系統(tǒng)整體的計算功耗比.鑒于異構眾核架構諸多優(yōu)勢,其如今已在事實上成為了當今高性能計算機建設的主流解決方案.

圖1 展示了目前典型的異構眾核架構,從總體上來說,該架構可以簡單地區(qū)分為Host端和Device端.Host端采用的CPU 具有多個物理上分開的Socket,而每個Socket 中有若干物理核心.這些核心是常規(guī)CPU 核心,能夠有效處理程序中復雜的邏輯判斷部分,因此程序的主進程運行在這些核心上.從內(nèi)存層次結構上看,當今多路多核CPU 一般具有多級數(shù)據(jù)和指令緩存.如圖1 所示,每個CPU 核心具有獨立的一級緩存(L1-cache),而處于同一Socket 的若干CPU 核心共享二級Cache(L2-cache),可有效加速多個CPU 核心間共享數(shù)據(jù)或指令的訪問.而作為CPU 與內(nèi)存之間的橋梁,三級Cache(L3-cache)用來提高CPU 整體的訪存速度.從圖1 中還可以看到,異構眾核系統(tǒng)的內(nèi)存和CPU 的各個Socket 一樣也是物理上獨立的,每個Socket 都有與自己鄰近的一塊物理內(nèi)存,該Socket 上的CPU 核心能夠以較低的延遲訪問近端內(nèi)存,但若訪問遠端內(nèi)存則延遲大幅度提高.各個Socket直接由高速網(wǎng)絡互聯(lián),并在硬件上實現(xiàn)了訪存一致性協(xié)議,形成cc-NUMA(cache coherent non-uniform memory access)結構,使得各個CPU 核心能在邏輯上共享一致的內(nèi)存空間.值得注意的是,緩存一致性協(xié)議及遠端內(nèi)存訪問會帶來較大的開銷,一種比較通用的方法是將各個進程分布在不同的Socket 上使得各個進程僅利用與該Socket 毗鄰的資源.

目前Device端可以配備多個協(xié)處理器設備.這些協(xié)處理器相對于CPU 來說具有很高的計算能力.這樣強大的計算能力一般是通過大規(guī)模并行計算實現(xiàn).以當今主流的GPGPU 為例,一塊GPGPU 卡中包含了眾多流處理器,這些處理器結構相對簡單而不適合處理邏輯復雜的代碼,但這些流處理器在硬件上整合了大量的向量計算部件并實現(xiàn)了高效的線程切換機制.這樣,一個流處理器能夠高效地調度大量線程予以向量化并行執(zhí)行.協(xié)處理器擁有獨立的內(nèi)存空間,一般通過PCI-e 總線與Host端的內(nèi)存進行數(shù)據(jù)交換.

雖然上述異構架構較為普及,但以往對 大規(guī)模超級計算機上HPL 測試程序的優(yōu)化工作的開展大多基于進程與協(xié)處理器一一對應這一前提[4?6].這種方案易于優(yōu)化,也可避免緩存一致性協(xié)議及訪問遠端內(nèi)存帶來的開銷.但在HPL 程序的實際執(zhí)行過程中,這種方案將不可避免地導致大量處理器空閑,并增加結點內(nèi)進程間通信開銷.在本文中,我們面向高度異構架構提出一套新型HPL 測試程序Hetero-HPL,突破以往進程與協(xié)處理必須一一對應這一限制,使用進程內(nèi)多協(xié)處理級并行方案,進而研究基于此方案的性能優(yōu)化方法,在執(zhí)行過程中更充分地利用各種硬件資源.

Fig.1 Typical architecture of multi-device heterogeneous platform圖1 典型多設備異構平臺架構

2 HPL算法概要

本節(jié)僅簡要介紹HPL 程序執(zhí)行過程中與本文工作相關的大致流程,關于各種算法細節(jié)可以參考[3,7?9]等,在此不再贅述.HPL 測試程序以多進程分布式的方式求解線性方程組Ax=b.矩陣A以二維循環(huán)塊卷簾(block cyclic)的方式分布在二維矩形進程拓撲上.由于進程拓撲設置具有自由性,而HPL 測試常?；谡叫芜M程拓撲結構而展開,因此本文僅討論典型的正方形進程拓撲下的HPL 分解算法,但本文工作也可用于非正方形進程拓撲結構的HPL 測試.

HPL 程序首先采用部分選主元(patial pivoting)的方式對隨機矩陣A進行LU 分解,之后進行回代求解向量b.由于其絕大部分計算量集中在對矩陣A的LU 分解部分,對HPL算法的性能優(yōu)化工作主要圍繞該部分展開.對矩陣A的LU 分解操作從邏輯上可以分為Panel 分解及Update(尾子矩陣更新)兩個部分.圖2 展示了HPL 程序在3×3 進程拓撲下的大體執(zhí)行流程.

在圖2 中我們可以看到,對矩陣A的LU 分解過程以由多個迭代步驟完成.在每次迭代過程中,首先處于某一特定列(簡稱P-Fact 列)的所有進程協(xié)作完成Panel 的分解.Panel 分解完成對當前瘦高子矩陣(panel)的部分選主元過程的LU 分解操作.從具體算法上看,Panel 分解可選擇向左或向右看(left/right looking)或Crout LU 分解算法.這三者計算量大致相等,具體的選擇可根據(jù)實際運行的效率決定.P-Fact 列的進程在Panel 分解執(zhí)行之后,通過數(shù)據(jù)傳輸,將產(chǎn)生的行交換信息(dpiv),Panel 分解的結果矩陣(L1 和L2)分享給同一進程行中的其他進程列,并開始接下來的Update 操作.在此值得一提的是,在Panel 分解過程所涉及的計算從形式上說具有邏輯復雜,小規(guī)模反復執(zhí)行等特點,并行度較小.因此線程啟停開銷,函數(shù)調用,數(shù)據(jù)傳輸開銷將嚴重制約Panel 分解過程的效率.因此其不適合采用Device端加速設備執(zhí)行.

Fig.2 One iteration of HPL algorithm圖2 HPL算法單次迭代

在Panel 分解執(zhí)行完畢之后,所有列的進程開始執(zhí)行Update 過程.在該過程中擁有矩陣U(或其某一部分)的進程行我們稱為U行進程.這些進程將U中待交換的矩陣行集合后配合其他行進程完成矩陣對應列的分布式行交換過程,其結果是每一進程都擁有自身矩陣對應所需的U矩陣.之后,參與Update 操作的所有進程分別利用得到的L1 矩陣對交換后的U矩陣進行dtrsm(三角矩陣求解)更新,并利用得到的L2 矩陣和矩陣U對所屬自身的尾子矩陣調用dgemm(矩陣乘法)完成更新.

不論進程與CPU 以怎樣的方式對應,HPL算法中占據(jù)絕大部分計算量的尾子矩陣更新操作都能完全利用所有協(xié)處理器完成.在該過程通過協(xié)處理進行充分加速之后,其余的零散計算的資源使用率將成為性能瓶頸.其中典型的有Panel 分解操作及處于Update 階段的分布式行交換操作.從算法流程上,在HPL 的每一次迭代步驟中,只有特定P-Fact 列進程完成本次迭代所需的Panel 分解操作,同時也只有U行進程參與矩陣U的廣播.因此不同的進程與處理器的映射關系會導致不同的資源使用情況.圖3 展示了一個由4 個實驗節(jié)點(具體參數(shù)介紹見第5.1 節(jié))組成的分布式環(huán)境.圖3 左側展示了進程與Socket 一一對應的情況.由于每一個Socket 僅管理8 個CPU 核心和一個協(xié)處理設備.因此在P-Fact 過程中只有共計8×4=32 個CPU 核心參與Panel 分解運算,而在Update 階段的行交換過程中,僅有4 個協(xié)處理器完成對U矩陣的打包并由對應的4 道PCI-e 總線進行傳輸.若采用圖3 右側進程與節(jié)點(node)一一對應的方式執(zhí)行HPL 程序,每個進程管控4 個協(xié)處理器設備,則在Panel 分解部分將有8×4×2=64 個CPU 核心參與計算,而在Update 階段的行交換過程中會有8 個協(xié)處理器及其PCI-e總線參與.隨著協(xié)處理器運算能力的進一步增長,占絕大部分計算量的BLAS 3 級函數(shù)能夠很快完成,而諸如Panel 分解,數(shù)據(jù)打包等必要步驟的運行時間比重將進一步加大,因此應在這些步驟中應盡可能地充分利用各種硬件資源.

Fig.3 Different mappings between processes and nodes圖3 進程與節(jié)點的不同對應關系

3 Hetero-HPL 總體結構

為了提高HPL 各個階段的資源利用率.本文提出Hetero-HPL 方案.總體上,Hetero-HPL 中每一個進程能夠管理任意數(shù)量的協(xié)處理器,在大幅度提高上述關鍵計算步驟的資源利用率的前提下,以協(xié)處理器間高度負載均衡的方式完成HPL 計算.Hetero-HPL 對原始HPL算法做出的改動可歸納為數(shù)據(jù)映射及操作映射兩個方面,分別對應于如圖4 所示的MD_Mapping 框架及MD_Primitive算法庫.它們將在本節(jié)中分別予以介紹.

Fig.4 Architecture of Hetero-HPL圖4 Hetero-HPL 總體結構

3.1 Hetero-HPL數(shù)據(jù)映射

在數(shù)據(jù)映射部分,Hetero-HPL 要解決如下3 個問題:(1) 確保Update 中BLAS 3 函數(shù)完全由協(xié)處理器(組)完成,以接近計算平臺的理論性能峰值;(2) 各個協(xié)處理器間計算相互獨立,以避免冗余的跨協(xié)處理器的數(shù)據(jù)交換及相互依賴;(3) 在每一次迭代過程中,各個協(xié)處理器間應保持負載均衡.為同時解決這3 個問題,我們?yōu)槌砻芫仃囋趨f(xié)處理器間進行數(shù)據(jù)劃分提供一套框架,名為Matrix-Device_Mapping(簡稱MD_Mapping),提供高層接口便于開發(fā)者在邏輯上訪問任意子矩陣,屏蔽了數(shù)據(jù)物理分布細節(jié).

如圖5 所示,在每一個進程中MD_Mapping 框架將HPL 程序生成的初始偽隨機矩陣劃分到各個協(xié)處理器.由于在Update 階段,同一進程上的各個矩陣列間的操作是獨立的,因此最自然的數(shù)據(jù)劃分策略即為按矩陣列進行劃分,以NB為寬度形成若干個列塊.由于計算過程中,尾子矩陣的規(guī)模逐漸變小,若按照列方向線性劃分并指派到各個協(xié)處理,則會導致協(xié)處理負載不均衡問題.因此,我們在MD_Mapping庫中采用按列塊循環(huán)卷簾的方式將諸多列塊平均分配到各個協(xié)處理上.MD_Mapping庫以描述符的方式選取原始矩陣的任意子矩陣,即便這些子矩陣在物理上分布于不同的協(xié)處理器.運算圍繞相關子矩陣實現(xiàn).值得注意的是,假如我們對各個協(xié)處理器從0 開始依次進行編號,并采用MD_Mapping 中使用的列塊循環(huán)卷簾數(shù)據(jù)排布方式,在同一列的不同進程上,原始矩陣中同一列元素所在的協(xié)處理器編號是相等的.這便于今后采用協(xié)處理間直接通信機制來優(yōu)化Hetero-HPL程序性能.

Fig.5 Matrix partition based on MD_Mapping framework圖5 基于MD_Mapping 框架的矩陣劃分

3.2 Hetero-HPL操作映射

在Update 階段,HPL算法主要涉及3 種操作:(1) (分布式)行交換;(2) 上三角矩陣更新dtrsm;(3) 尾子矩陣乘更新dgemm.而在具有多設備的異構眾核平臺上,數(shù)據(jù)在Host 及Device 之間數(shù)據(jù)一致性也需要通過數(shù)據(jù)傳遞來實現(xiàn).因此,我們在 MD_Mapping 框架上實現(xiàn)了 MD_Primitive庫.MD_Primitive 層以MD_Mapping 提供的子矩陣描述符為操作對象,調用所有相關協(xié)處理器協(xié)同(并行)完成施加于目標子矩陣的操作,如數(shù)據(jù)傳遞,三角矩陣更新和矩陣乘更新等.另外,MD_Primitive 中的函數(shù)調用接口皆為異步接口,可以方便實施多操作重疊執(zhí)行.在具備MD_Mapping 框架及MD_Primitive庫之后,Hetero-HPL 的大致程序結構如圖6 所示,其中,綠色字體代表同步調用,紅色字體代表異步調用.

在整體算法開始之前,MD_Mapping 已經(jīng)完成了對初始系統(tǒng)Ax=b的映射,生成映射實例MatrixMapping.由于Hetero-HPL 主要對HPL算法的Update 階段進行了重構,因此我們圍繞Update 階段進行闡述,其偽代碼如圖6 左側所示.通過MatrixMapping 實例,程序獲取兩個子矩陣描述符(第3 行～第6 行),分別為 NextPanel(下一 Panel)及 TrailingMatrix(尾子矩陣).這兩個子矩陣實例的實際數(shù)據(jù)分布細節(jié)被MD_Mapping 框架屏蔽.MD_Mapping 為每個設備預留了數(shù)據(jù)緩存L(可進一步劃分為L1 和L2)用來放置分解完畢的Panel 數(shù)據(jù).各個子矩陣實例可按需要分配屬于自身的Device端數(shù)據(jù)緩存U.數(shù)據(jù)緩存L及U將在接下來的步驟中使用,包括行交換(第11 行及第18 行),上三角矩陣更新(第12 行及第19 行)和矩陣乘更新(第13 行及第20 行).這些步驟由MD_Primitive庫中函數(shù)實現(xiàn).我們將施加于NextPanel 的所有運算完成之后,開啟異步傳輸(第15 行),從對應的設備上將NextPanel 的數(shù)據(jù)拷貝回Host端內(nèi)存,進而完成下一次Panel 分解操作.與此同時,對TrailingMatrix 的上三角矩陣更新及矩陣乘更新可以通過異步接口與下一次Panel 分解并行執(zhí)行,如圖6 右側所示.

Fig.6 Pesudo-code of Hetero-HPL based on MD_Mapping and MD_Primitive圖6 基于MD_Mapping 及MD_Primitive 實現(xiàn)的Hetero-HPL 偽代碼

4 面向異構平臺的實現(xiàn)及優(yōu)化

4.1 突破鎖頁內(nèi)存分配大小限制

在現(xiàn)在主流異構平臺上,Host端內(nèi)存和Device端協(xié)處理器內(nèi)存的數(shù)據(jù)交換主要通過PCI-e 總線完成.若要盡可能充分地利用PCI-e 總線的帶寬(約32GB/s,全雙工)則需要在Host端開辟鎖頁內(nèi)存(pinned memory).鎖頁內(nèi)存的最大特點是其不會被操作系統(tǒng)換出到硬盤交換區(qū),以便于設備端建立物理地址映射,因此對協(xié)處理器來說可以通過DMA 機制高速訪問.相比于以常規(guī)方式申請的內(nèi)存空間來說,鎖頁內(nèi)存能夠擁有2～3 倍的訪問速率.然而,鎖頁內(nèi)存一般為連續(xù)的物理內(nèi)存空間,其申請受到單一NUMA 節(jié)點上內(nèi)存大小的限制.為確保數(shù)據(jù)在Host端及Device端對應,在擁有若干協(xié)處理平臺上,單次申請的鎖頁內(nèi)存容量很可能遠小于所有設備內(nèi)存的總和[10].因此,面向 Hetero-HPL,我們對原始矩陣建立軟件緩存,采用若干鎖頁內(nèi)存來替代非鎖頁內(nèi)存.

如圖7 所示,以目標平臺為例,假設原始矩陣大小為64GB,在Hetero-HPL 中,我們開辟兩片(或多片)鎖頁內(nèi)存區(qū)域(大小都為32GB),然后采用同樣的偽隨機數(shù)生成算法直接初始化這兩片內(nèi)存區(qū)域.之后,在LU 分解的過程中,Hetero-HPL 直接與這兩片鎖頁內(nèi)存完成多次矩陣Panel 的相互交換.值得一提的是,原始的64GB非鎖頁內(nèi)存區(qū)域在Hetero-HPL 執(zhí)行過程中并不需要真實存在,因此Hetero-HPL 并不會帶來冗余內(nèi)存消耗.通過簡單的地址變換,Hetero-HPL 也不會通過大量冗余操作來進行數(shù)據(jù)傳輸.在Hetero-HPL 執(zhí)行完成之后,我們獲取解向量b并釋放掉所有鎖頁內(nèi)存.之后再由驗證程序在64GB 非鎖頁內(nèi)存中重建整個線性系統(tǒng),進而完成結果驗證.

Fig.7 Original un-pinned memory is replaced by two pinned memory regions圖7 采用兩片鎖頁內(nèi)存區(qū)域替代原始非鎖頁內(nèi)存

4.2 同一協(xié)處理器上相同操作的歸并

Fig.8 Merge of the same operation on each co-processor圖8 協(xié)處理器上同種操作的歸并

由于我們采用了按列塊循環(huán)卷簾的方式在各個協(xié)處理器上分配矩陣數(shù)據(jù),而每一列塊的列數(shù)僅為NB(通常為128,256,512 等),因此施加在某一列塊上的操作(如矩陣乘dgemm 函數(shù))可能會由于其數(shù)據(jù)規(guī)模過小而無法充分發(fā)揮協(xié)處理器的大規(guī)模并行計算能力.針對HPL算法程序,由于各個列塊間計算相互獨立,我們可以利用矩陣不同列間計算的結合律,讓位于同一協(xié)處理的所有列塊同時執(zhí)行相同操作,即便這些列塊在邏輯上并不相連.如圖8 虛線框所示的子矩陣,其由多個列塊構成.在每一個協(xié)處理器上,我們只需調用一次dgemm 函數(shù)就可以完成該協(xié)處理器上所有列塊的更新.類似地,同一進程中的行交換,dtrsm 等操作也可以進行歸并,故不再贅述.

4.3 Panel分解與協(xié)處理器組異步并行

Panel 分解過程的各個步驟由于計算規(guī)模小,調用頻繁而不利于使用協(xié)處理器進行加速.因此,在當前的Hetero-HPL 版本中,我們將Panel 分解放置在CPU端執(zhí)行.如前文所述,相對于進程與協(xié)處理一一對應的方案而言,在Hetero-HPL 中Panel 分解操作將有條件利用更多CPU 核心來完成計算.在HPL算法中下一次迭代步的Panel 分解可以和當前次迭代的尾子矩陣dgemm 更新并行執(zhí)行.我們結合MD_Primitive庫中的異步函數(shù)接口,可以很輕易地完成上述兩個關鍵步驟的異步并行執(zhí)行.

4.4 相關Kernel的優(yōu)化實現(xiàn).

由于待分解的矩陣被置于協(xié)處理器內(nèi)存中,因此我們需要手工編寫協(xié)處理器代碼以實施相應運算.對于BLAS 函數(shù),我們可以直接調用RocBLAS庫.而對于諸如行交換,矩陣轉置等操作則需要我們手工編寫計算Kernel 完成.在此過程中,我們一方面要利用協(xié)處理器的大規(guī)模并行能力,另一方面我們也需要利用計算的可結合性,盡量在一次Kernel 啟動中完成同一協(xié)處理器上所有數(shù)據(jù)的計算.

5 實 驗

5.1 實驗平臺簡介

Hetero-HPL 面向當前主流的多協(xié)處理器架構構建,因此我們采用一個多核CPU+多個GPU 的典型異構系統(tǒng)作為實驗平臺.實驗平臺具有Host端及Device端.Host端采用4 路8 核Intel 指令集架構.與每路CPU 核心鄰近的內(nèi)存大小為32GB,系統(tǒng)共計128GB 內(nèi)存空間.Device端為4 個類GPGPU 設備,每塊類GPGPU 擁有64 個流處理器,16GB 設備內(nèi)存.實驗平臺Host端支持Posix 標準.因此可以采用常用的并行編程模型如MPI、OpenMP 等.而對于Device端的類GPGPU 設備,實驗平臺提供基礎并行編程環(huán)境Hip,并擁有開源基礎并行算法庫Rocm[10].類似于NVIDIA 公司推出的通用顯卡計算編程環(huán)境CUDA 及其加速算法庫CUDA Toolkit[11],實驗平臺能夠支持手工編寫并編譯適用于Device端運行的計算kernel,還可以直接利用Rocm算法庫中的高性能函數(shù)實現(xiàn)并優(yōu)化程序.另外,HPL 程序的高效執(zhí)行離不開底層高效執(zhí)行的基礎線性代數(shù)庫 BLAS.在Host端,實驗平臺采用BLIS[4]數(shù)學庫,其dgemm 執(zhí)行效率可以高達CPU 理論峰值性能的98%以上.而在Device端,我們同樣可以利用Rocm算法庫中的RocBLAS 數(shù)學庫模塊,其dgemm 性能約為單塊協(xié)處理器理論性能的84%以上.

5.2 單節(jié)點實驗結果

Hetero-HPL 可以支持所有128 倍數(shù)的NB取值.通過實驗我們發(fā)現(xiàn)NB=256 能夠取得較優(yōu)的總體性能.另外在NB=256 時,Device端矩陣乘法效率大約為機器峰值性能的84%.我們選取31 個CPU 核心參與Panel 分解計算,也能獲得較優(yōu)的總體性能.

圖9 展示了Hetero-HPL 在單節(jié)點單進程情況下的運行效率.隨著矩陣規(guī)模的擴大,執(zhí)行效率呈現(xiàn)大幅度上升趨勢.在矩陣階數(shù)達到88 320(4 個協(xié)處理器設備內(nèi)存占用率達到95.5%)時,Hetero-HPL 的運行效率達到了實驗平臺峰值性能的76.53%,同時也達到了dgemm 性能的91.11%,因此可見Hetero-HPL 在單節(jié)點單進程情況下能夠取得較優(yōu)的性能.

Fig.9 Efficiency trend of single process Hetero-HPL with respect to matrix rank圖9 單進程Hetero-HPL 執(zhí)行效率隨著矩陣階數(shù)變化趨勢

5.3 多節(jié)點實驗結果

圖10 展示了Hetero-HPL 在4～256 個節(jié)點的運行性能.實驗中每個進程的Device端內(nèi)存使用量達到96.0%.我們的工作展示了基于單進程控制多協(xié)處理器技術的 HPL算法在分布式環(huán)境下的測試結果.但意外的是,Hetero-HPL 雖然在算法層面并沒有引入多余的數(shù)據(jù)傳輸量,但是程序的性能隨著進程數(shù)的增加而大幅度降低.由于HPL算法本身具有很好的可擴展性,而在實際測量中我們發(fā)現(xiàn)通信所耗費的時間約為總體計算時間的25%～30%,因此我們認為通信效率成為制約Hetero-HPL 在分布式環(huán)境下擴展性的一個重要方面.

Fig.10 Scalability of Hetero-HPL on 4～256 nodes圖10 Hetero-HPL 在4～256 個節(jié)點可擴展性

Hetero-HPL 通信開銷表現(xiàn)在3 個方面.第一,PCI-e 總線利用率不高.以Panel 分解相關的節(jié)點內(nèi)傳輸為例,由于目前采用NB為列數(shù)按列方向劃分矩陣,使得任意一個Panel 從Device端拷貝到Host端僅能采用一路PCI-e總線.若使用NB/D(D為設備數(shù)量)為列數(shù)進行矩陣劃分并在設備間卷簾排布,則可以確保任意一個Panel 的數(shù)據(jù)均勻分布于所有設備,上述傳輸可以使用所有PCI-e 總線并行完成.另外第4.2 節(jié)所述的操作歸并技術亦可在更細粒度的數(shù)據(jù)劃分方案上使用,可確保設備端的計算性能.第二,Panel 分解階段并未實現(xiàn)計算通信重疊.我們認為能夠利用Panel 分解過程中BLAS 3 級函數(shù)來掩蓋部分Panel 相關的數(shù)據(jù)傳輸.第三,進程間的MPI 通信效率有待考證.由于Hetero-HPL 不能直接控制底層網(wǎng)絡資源(如多塊網(wǎng)卡),因此如何配置MPI 使其針對Hetero-HPL發(fā)揮最優(yōu)性能也是一個值得深入研究的問題.

6 相關工作

自從HPL 程序被提出并作為高性能計算評測標準,對其研究和改進及在不同平臺上的并行方案、優(yōu)化方法及計算模型研究就未曾中斷過.從早期的Intel Paragon 平臺上的實現(xiàn)與測試[12],到現(xiàn)今世界最快的超級計算機上的優(yōu)化與開拓[13],對HPL算法及優(yōu)化的研究一直在影響著計算機軟硬件設計與發(fā)展.異構平臺上的HPL 一般是主要由速度較快的加速器來完成矩陣更新操作,CPU 負責通信及Panel 分解[6,7].Wang 等為GPU+多核CPU平臺設計了分階段動態(tài)任務劃分的方法及軟件流水線,以充分利用計算和通信資源[8].Heinecke 等人針對帶有MIC 加速卡的平臺,做了細粒度多層次的任務劃分,從而實現(xiàn)對各部件的充分合理使用[9].Gan 等面向HPL 在國產(chǎn)加速器China accelerator 上對dgemm 進行了優(yōu)化,并使用靜態(tài)與動態(tài)相結合的調度方式來協(xié)調CPU 與加速器之間的工作[3].對多GPU 平臺上的HPL 研究,陳任之等人工作采用了與本文工作類似的單進程控制多協(xié)處理器案[14].但是由于其并沒有將尾子矩陣駐留于Device端,因此數(shù)據(jù)在Host端和Device端的來回傳輸對整體性能產(chǎn)生了負面影響.相似的方案也被AMD 公司采用,為HPL 中的dgemm 實現(xiàn)了單進程多設備版本[11].與上述兩個方案不同的是Hetero-HPL 在多協(xié)處理器環(huán)境中也實現(xiàn)了全局數(shù)據(jù)的駐留,根本上避免了尾子矩陣的搬移.Jia 等人提出了與Hetero-HPL 類似的解決方案,確保了數(shù)據(jù)多設備端的駐留并采用了按列塊循環(huán)卷簾數(shù)據(jù)結構確保數(shù)據(jù)負載均衡[6].但值得指出的是,Jia 等人沒有考慮到鎖頁內(nèi)存分配大小限制小于Device端所有設備內(nèi)存總量這一情況.在如本文所述的平臺上,該方案只能處理較小階數(shù)的矩陣,因而無法充分反映平臺性能,因此其單節(jié)點性能僅達到機器峰值性能的46.06%.另外,由于其方案采用了激進的動態(tài)調度策略,其復雜性也進一步降低了該方案在多進程環(huán)境中的可行性.在以上兩方面,本文工作更為深入.

7 總結與未來的工作

面向當今主流的異構高性能計算平臺,本文提出了Hetero-HPL 測試程序.整體上,Hetero-HPL 所依賴的數(shù)據(jù)對協(xié)處理器的映射規(guī)則,并行策略等并不依賴于具體的硬件架構及基礎軟件,因此有能力在現(xiàn)有多種主流眾核架構上進行部署.Hetero-HPL 還從根本上突破了進程數(shù)量與協(xié)處理器數(shù)量必須相等的限制,更進一步提高了其實用性.在執(zhí)行過程中,單個進程攜帶多個協(xié)處理器的配置有利于在Panel 分解和分布式行交換過程中利用更多了的計算資源,有利于執(zhí)行效率的提高.Hetero-HPL 基于MD_Mapping 框架和MD_Primitive庫,使占主要計算量的尾子矩陣更新步驟完全利用多個協(xié)處理器提供的大規(guī)模并行計算能力,同時也避免了同一進程中多個協(xié)處理器間相互數(shù)據(jù)交換并確保各協(xié)處理器間計算量的均衡.面向多設備異構平臺,我們突破了鎖頁內(nèi)存分配限制,利用多塊鎖頁內(nèi)存在邏輯上替代原始非鎖頁內(nèi)存,使Hetero-HPL Device端與Host端的內(nèi)存交換僅發(fā)生在鎖頁內(nèi)存中,確保了執(zhí)行的高效.在本文中,我們面向多設備異構系統(tǒng)嘗試了一些基礎但必要的優(yōu)化手段,其中包括Panel 分解與尾子矩陣dgemm 更新的異步并行,同一協(xié)處理器上相同計算的歸并及行交換相關操作在協(xié)處理器端的并行化實現(xiàn).實驗結果表明,在單節(jié)點條件下Hetero-HPL 達到了實驗平臺峰值性能的76.53%(dgemm實測性能的91.1%).Hetero-HPL 還展示了基于單進程控制多設備技術的HPL算法在多節(jié)點分布式環(huán)境下的可行性.但目前由于網(wǎng)絡通信及PCI-e 數(shù)據(jù)交換的開銷比例過大,程序執(zhí)行效率還需進一步提高,這是我們將要深入研究的一個重要方面.

基于Hetero-HPL,我們未來將主要開展兩方面的工作.一方面,進一步在目標平臺上深入優(yōu)化Hetero-HPL程序.其中包括深入挖掘Hetero-HPL 程序中的并行性,使更多關鍵步驟,如Panel 在Host端及Device端的來回傳遞、跨進程的廣播和分布式行交換等得以并行執(zhí)行;在此基礎上,分析各個步驟在各次迭代中的時間占比,基于動態(tài)信息反饋安排不同的異步并行方案.另一方面,我們可以在若干不同的平臺上實現(xiàn)Hetero-HPL,梳理制約Hetero-HPL 性能的一般性因素,為Hetero-HPL 的性能表現(xiàn)建立數(shù)學模型.