武林平，景翠萍，劉 旭，田鴻運(yùn)

(北京應(yīng)用物理與計(jì)算數(shù)學(xué)研究所， 北京 100094)

“塊同步并行”(Bulk Synchronous Parallel,BSP)模式(如圖1所示)的理想運(yùn)行情況下，為滿足負(fù)載平衡需求，任務(wù)被均勻地分配到并行程序的每個(gè)進(jìn)程，從而保證每個(gè)進(jìn)程都具有相同的計(jì)算性能、通信性能、訪存性能，進(jìn)而使得所有進(jìn)程均在相同的時(shí)刻到達(dá)同步點(diǎn)。然而，在實(shí)際運(yùn)行情況下，并行程序本身的算法特征、系統(tǒng)噪音的擾動(dòng)等因素將破壞這種負(fù)載平衡，使得各計(jì)算進(jìn)程不能在同一時(shí)刻到達(dá)同步點(diǎn)(并行程序的實(shí)際運(yùn)行過程如圖2所示)，從而引起進(jìn)程間的相互等待現(xiàn)象[1]。對(duì)于阻塞式的點(diǎn)對(duì)點(diǎn)通信而言，通信接收方的執(zhí)行進(jìn)度將依賴于通信發(fā)送方的進(jìn)度，在這個(gè)過程中，通信接收方從啟動(dòng)數(shù)據(jù)接收操作到實(shí)際開始接收數(shù)據(jù)的這段時(shí)間稱為通信等待時(shí)間[2]。聚合通信過程也類似，因?yàn)樗耐瓿尚枰總€(gè)進(jìn)程參與，當(dāng)少數(shù)進(jìn)程未能及時(shí)到達(dá)同一個(gè)聚合通信點(diǎn)時(shí)，將引起所有參與進(jìn)程的相互等待現(xiàn)象。

相關(guān)研究表明，MPI并行程序在運(yùn)行過程中，通信等待時(shí)間將構(gòu)成大規(guī)模并行程序通信時(shí)間的主要部分[2]。特別是將通信密集型應(yīng)用程序擴(kuò)展到大規(guī)模處理器核數(shù)時(shí)，這種通信等待現(xiàn)象將加劇，對(duì)實(shí)現(xiàn)高性能的并行應(yīng)用程序提出了嚴(yán)峻的挑戰(zhàn)。

圖1 BSP并行程序的理想運(yùn)行過程Fig.1 Ideal state of BSP parallel program

圖2 BSP并行程序的實(shí)際運(yùn)行過程Fig.2 Real state of BSP parallel program

1 通信等待問題的診斷方法相關(guān)研究

1.1 MPI通信等待模式

通常，MPI并行程序中通信等待現(xiàn)象最初是由同步點(diǎn)之前的計(jì)算負(fù)載不均衡或通信不均衡等原因引發(fā)的。但各類因素之間的相互干擾及傳播效應(yīng)，將造成通信等待現(xiàn)象存在于MPI并行程序的全部運(yùn)行過程中。這種“現(xiàn)象”與“原因”之間的復(fù)雜關(guān)聯(lián)關(guān)系，使得定位導(dǎo)致通信等待問題的根本原因的診斷過程變得非常復(fù)雜。例如某個(gè)計(jì)算過程在某段時(shí)間內(nèi)計(jì)算負(fù)載不均衡，但下個(gè)時(shí)刻這種負(fù)載不均衡現(xiàn)象可能與其他計(jì)算過程的負(fù)載不均衡現(xiàn)象相互抵消，這種負(fù)載不均衡現(xiàn)象并不會(huì)導(dǎo)致MPI通信等待問題。

因此，分析通信等待現(xiàn)象如何形成、在何處形成，對(duì)于快速準(zhǔn)確地找到其根本原因從而消除通信等待現(xiàn)象至關(guān)重要。文獻(xiàn)[2]詳細(xì)分析了MPI并行程序中點(diǎn)對(duì)點(diǎn)通信、聚合通信以及同步過程中可能出現(xiàn)的各種通信等待模式。文獻(xiàn)[3]提出了一種名為FACT的Trace分析技術(shù)，可在小規(guī)模系統(tǒng)上低開銷地獲取大規(guī)模并行程序的通信軌跡數(shù)據(jù)，采用人工分析方法可識(shí)別MPI并行程序中的通信等待模式。參考MPI-3標(biāo)準(zhǔn)，MPI通信過程中主要存在以下幾種常見的通信等待模式[2]：

1)點(diǎn)對(duì)點(diǎn)通信過程中：存在2種典型的通信等待模式，包括晚發(fā)送模式和晚接收模式，分別如圖3(a)和圖3(b)所示。

2)同步過程(MPI_Barrier)中：同步過程中出現(xiàn)的通信等待問題主要是因?yàn)檫M(jìn)程不能及時(shí)到達(dá)同步點(diǎn)產(chǎn)生的，主要形成過程如圖3(c)所示，稱為早同步模式。

3)聚合通信過程中：存在多種典型的通信等待模式，包括晚廣播模式、早規(guī)約模式以及全局交換模式等，其中早規(guī)約模式如圖3(d)所示。在早規(guī)約模式下，進(jìn)程過早參與聚合通信，導(dǎo)致這些進(jìn)程上出現(xiàn)通信等待現(xiàn)象。以此類推，其他聚合通信等待模式的形成過程也是類似的。

(a) 晚發(fā)送模式(a) Late sender pattern

(b) 晚接收模式(b) Late receiver pattern

(c) 早同步模式(c) Early barrier pattern

(d) 早規(guī)約模式(d) Early reduce pattern圖3 常見的MPI通信等待模式Fig.3 Scheme of MPI communication waiting

1.2 通信等待模式的量化分析方法

針對(duì)以上幾種常見的通信等待模式，相關(guān)研究主要從原因定位、通信等待時(shí)間量化分析、通信等待問題診斷模型(Diagnostic Model for Communication Waiting Problem, CWP-DM)3個(gè)方面，詳細(xì)分析了MPI并行程序中通信等待問題形成的原因以及可能產(chǎn)生的影響。

為了更加清楚地闡述該問題，下面首先給出超時(shí)時(shí)間、等待時(shí)間、同步間隔這3個(gè)關(guān)鍵詞的具體含義。

1)超時(shí)時(shí)間：特指造成通信等待現(xiàn)象的原因，例如某代碼段在進(jìn)程p上的運(yùn)行時(shí)間遠(yuǎn)超平均值，超出平均值的時(shí)間即為超時(shí)時(shí)間。一般來講，MPI并行程序的超時(shí)時(shí)間將存在于多個(gè)代碼段，這些超時(shí)時(shí)間將逐步累加，最終導(dǎo)致通信等待現(xiàn)象的發(fā)生。

2)等待時(shí)間：指進(jìn)程已參與MPI通信但仍處于空閑等待狀態(tài)的時(shí)間，是通信等待現(xiàn)象的表現(xiàn)形式。

3)同步間隔：進(jìn)程p和進(jìn)程q的兩個(gè)相鄰?fù)近c(diǎn)之間的時(shí)間間隔稱為一個(gè)同步間隔。在一個(gè)同步間隔內(nèi)，進(jìn)程p和進(jìn)程q之間沒有其他同步點(diǎn)。

1.2.1 通信等待問題形成的原因

圖4以點(diǎn)對(duì)點(diǎn)通信等待模式為例，采用時(shí)間線圖描述MPI并行程序中由于計(jì)算負(fù)載不均衡、通信不均衡等引發(fā)的通信等待現(xiàn)象[4]。其中，不同進(jìn)程上執(zhí)行的函數(shù)都以不同顏色的矩形方框表示，矩形方框的長(zhǎng)度表示每個(gè)函數(shù)的執(zhí)行時(shí)間，進(jìn)程間帶箭頭的線段表示進(jìn)程間的通信關(guān)系或同步關(guān)系。例如，S1表示進(jìn)程1上執(zhí)行的MPI_Send函數(shù)，S2表示進(jìn)程2上執(zhí)行的MPI_Send函數(shù)，R1表示進(jìn)程2上執(zhí)行的MPI_Recv函數(shù)，comp表示計(jì)算函數(shù)。

圖4 MPI并行程序中通信等待問題的時(shí)間線圖Fig.4 Time-line diagram of communication waiting in MPI parallel program

在圖4中，進(jìn)程2和進(jìn)程3都出現(xiàn)了通信等待現(xiàn)象，顯示為進(jìn)程2和進(jìn)程3上的陰影區(qū)域。MPI并行程序中通信等待現(xiàn)象可分為直接等待現(xiàn)象和間接等待現(xiàn)象。由于某個(gè)進(jìn)程上函數(shù)的執(zhí)行時(shí)間超時(shí)直接引發(fā)另一個(gè)進(jìn)程上出現(xiàn)的等待現(xiàn)象稱為直接等待現(xiàn)象，產(chǎn)生的等待時(shí)間稱為直接等待時(shí)間；直接等待現(xiàn)象進(jìn)一步傳播而引發(fā)的通信等待現(xiàn)象稱為間接等待現(xiàn)象，由此產(chǎn)生的等待時(shí)間稱為間接等待時(shí)間[5]。在圖4示例中，進(jìn)程2上的通信函數(shù)R1產(chǎn)生了直接等待時(shí)間，它是由進(jìn)程1上執(zhí)行的函數(shù)comp計(jì)算超時(shí)引起的。與此同時(shí)，進(jìn)程2上出現(xiàn)的直接等待現(xiàn)象又進(jìn)一步引發(fā)進(jìn)程3上出現(xiàn)間接等待現(xiàn)象，因此進(jìn)程3上產(chǎn)生了間接等待時(shí)間。除此之外，進(jìn)程3上還產(chǎn)生了直接等待時(shí)間，這是由于進(jìn)程2上的通信函數(shù)R1執(zhí)行時(shí)間超時(shí)引起的。

1.2.2 通信等待時(shí)間量化分析

通常采用Trace分析技術(shù)檢測(cè)MPI并行程序中的通信等待時(shí)間。文獻(xiàn)[6]針對(duì)MPI并行程序中點(diǎn)對(duì)點(diǎn)通信和聚合通信，提出了一種測(cè)量通信等待時(shí)間的方法：首先記錄MPI通信和同步操作在每個(gè)進(jìn)程上的執(zhí)行時(shí)間，然后計(jì)算時(shí)間位移從而獲取通信等待時(shí)間。文獻(xiàn)[7]針對(duì)MPI單邊通信，提出了一種測(cè)量通信等待時(shí)間的方法，該方法借鑒了文獻(xiàn)[4]中的研究思路。

本文中，用二元組(p,i)來描述進(jìn)程p上執(zhí)行的函數(shù)i。理想情況下，參與通信的進(jìn)程應(yīng)同時(shí)開始執(zhí)行相應(yīng)的通信函數(shù)。如果進(jìn)程p上的通信函數(shù)(p,i)的完成取決于另一個(gè)進(jìn)程q上執(zhí)行的函數(shù)(q,k)，并且進(jìn)程p在進(jìn)程q開始執(zhí)行函數(shù)(q,k)之前開始執(zhí)行函數(shù)(p,i)，則這兩個(gè)函數(shù)形成了一個(gè)同步點(diǎn)。因此，同步點(diǎn)S=((p,i),(q,k))是函數(shù)(p,i)和函數(shù)(q,k)的二元組，并且同步點(diǎn)的形成需要滿足以下條件[8]：

1)函數(shù)(p,i)的完成取決于函數(shù)(q,k)；

2)函數(shù)(p,i)比函數(shù)(q,k)開始執(zhí)行得早，即Enter(p,i)

3)兩個(gè)函數(shù)存在重疊的執(zhí)行時(shí)間，即Exit(p,i)>Enter(q,k)。

因此，對(duì)于進(jìn)程p上執(zhí)行函數(shù)(p,i)和進(jìn)程q上執(zhí)行函數(shù)(q,k)的這段時(shí)間內(nèi)，進(jìn)程p上執(zhí)行的函數(shù)(p,i)出現(xiàn)通信等待現(xiàn)象。其中，等待時(shí)間可量化[9]為：

w(p,i)=Enter(q,k)-Enter(p,i)

(1)

式(1)不僅適用于點(diǎn)對(duì)點(diǎn)通信等待模式，而且適用于同步等待模式和聚合通信等待模式。對(duì)于后者，進(jìn)程q特指最晚參與同步過程或最晚參與聚合通信的進(jìn)程。

1.2.3 通信等待問題診斷模型

通?；谕ㄐ诺却龁栴}診斷模型可定位導(dǎo)致通信等待問題的關(guān)鍵函數(shù)，然后人工分析這些關(guān)鍵函數(shù)的詳細(xì)執(zhí)行行為，最終定位導(dǎo)致通信等待問題的根本原因。文獻(xiàn)[9]中提出了一種通信等待問題診斷模型，給出了在所有同步間隔中某個(gè)函數(shù)調(diào)用路徑導(dǎo)致的直接等待時(shí)間和間接等待時(shí)間，見式(2)：

(2)

該診斷模型考慮了多方面因素的影響，分析了直接等待時(shí)間和間接等待時(shí)間形成的根本原因，并且需要對(duì)MPI并行程序中所有函數(shù)調(diào)用路徑展開詳細(xì)的測(cè)量與分析[10]。然而，在實(shí)際應(yīng)用過程中，測(cè)量發(fā)現(xiàn)這種診斷模型耗費(fèi)的內(nèi)存開銷較大，比如LARED集成程序[11]在1024核運(yùn)行時(shí)單進(jìn)程的內(nèi)存開銷高達(dá)16 GB，測(cè)量數(shù)據(jù)見表1。文獻(xiàn)[8]中還指出，將上述模型應(yīng)用到Sweep3D程序中，測(cè)量時(shí)間和內(nèi)存開銷隨著并行規(guī)模的擴(kuò)大將快速增長(zhǎng)。除此之外，過大的測(cè)量開銷將導(dǎo)致性能數(shù)據(jù)出現(xiàn)偏差，從而導(dǎo)致診斷算法誤報(bào)率增大。對(duì)于內(nèi)存受限的高性能計(jì)算機(jī)系統(tǒng)(例如平均單核內(nèi)存少于2 GB)，上述模型引入的測(cè)量開銷甚至可能造成診斷失效。

表1 LARED程序運(yùn)行1000個(gè)時(shí)間步單進(jìn)程的內(nèi)存開銷Tab.1 Memory overhead for LARED program running in 1000 time steps

2 基于熱點(diǎn)函數(shù)的通信等待問題診斷方法

2.1 診斷模型

根據(jù)以上分析，考慮測(cè)量開銷可控、診斷算法誤報(bào)率低的實(shí)際需求，需要精簡(jiǎn)通信等待問題診斷模型，降低測(cè)量與分析開銷。對(duì)于MPI并行程序，定位間接等待現(xiàn)象產(chǎn)生的原因?qū)?huì)帶來額外的開銷，并且直接等待現(xiàn)象消除后，間接等待現(xiàn)象也隨之消除。因此，本文建立的通信等待問題診斷模型不再考慮直接等待現(xiàn)象的傳播對(duì)程序性能的間接影響，只定位導(dǎo)致直接等待現(xiàn)象的計(jì)算超時(shí)或通信超時(shí)函數(shù)。另外，程序的性能瓶頸大多是由于性能熱點(diǎn)函數(shù)引發(fā)的，為了更精準(zhǔn)定位通信等待問題，本文建立的通信等待問題診斷模型首先從熱點(diǎn)函數(shù)引發(fā)的通信等待時(shí)間入手。例如，可選取執(zhí)行時(shí)間大于1%的函數(shù)作為熱點(diǎn)函數(shù)。

在一個(gè)同步間隔內(nèi)，進(jìn)程p上的函數(shù)(p,c)的執(zhí)行時(shí)間由式(3)計(jì)算給出。為了準(zhǔn)確反映每個(gè)函數(shù)對(duì)MPI并行程序的通信等待時(shí)間形成的影響，式(3)排除了直接等待現(xiàn)象的傳播對(duì)程序性能產(chǎn)生的間接影響。

t(p,c)=Exit(p,c)-Enter(p,c)-w(p,c)

(3)

在一個(gè)同步間隔內(nèi)，進(jìn)程p上執(zhí)行的函數(shù)(p,c)的超時(shí)時(shí)間則是由函數(shù)c在進(jìn)程q和進(jìn)程p上的執(zhí)行時(shí)間之間的差值計(jì)算得出，見式(4)。在一個(gè)同步間隔內(nèi)，由于執(zhí)行時(shí)間差為負(fù)數(shù)的函數(shù)不會(huì)引起進(jìn)程p出現(xiàn)通信等待現(xiàn)象，因此這部分時(shí)間忽略不計(jì)。

(4)

根據(jù)以上分析，針對(duì)MPI并行程序，建立基于熱點(diǎn)函數(shù)的通信等待問題診斷模型(Diagnostic Model for Communication Waiting Problem based on Hotspots, H-CWP-DM)，見式(5)。

(5)

該診斷模型通過比較一個(gè)同步間隔內(nèi)各熱點(diǎn)函數(shù)的執(zhí)行時(shí)間來定位超時(shí)時(shí)間較大的函數(shù)，從而確定導(dǎo)致通信等待問題的關(guān)鍵函數(shù)，并可給出這些關(guān)鍵函數(shù)產(chǎn)生的通信等待時(shí)間。通過該診斷模型，可定位產(chǎn)生通信等待時(shí)間比較大的關(guān)鍵函數(shù)，然后分析這些關(guān)鍵函數(shù)的詳細(xì)執(zhí)行行為，最終可以定位產(chǎn)生通信等待問題的根本原因。除此之外，式(5)建立的診斷模型不僅適用于點(diǎn)對(duì)點(diǎn)通信等待模式，而且適用于同步等待模式和聚合通信等待模式。對(duì)于后者，進(jìn)程q特指最晚參與同步活動(dòng)或最晚參與聚合通信的進(jìn)程，并且選取最早參與同步活動(dòng)或最早參與聚合通信活動(dòng)的進(jìn)程p來分析進(jìn)程p上產(chǎn)生通信等待現(xiàn)象的根本原因。

2.2 診斷流程

基于H-CWP-DM診斷模型，總結(jié)出精簡(jiǎn)版、更實(shí)用的通信等待問題診斷流程，主要包括以下步驟：

步驟1：測(cè)量并分析MPI并行程序運(yùn)行時(shí)的性能熱點(diǎn)函數(shù)。

步驟2：測(cè)量MPI并行程序的通信等待時(shí)間，確定通信等待時(shí)間對(duì)應(yīng)的同步間隔。

步驟3：根據(jù)H-CWP-DM診斷模型，定位產(chǎn)生通信等待時(shí)間比較大的關(guān)鍵函數(shù)。

步驟4：從計(jì)算、訪存、通信等方面分析關(guān)鍵函數(shù)的詳細(xì)執(zhí)行行為，明確產(chǎn)生通信等待問題的根本原因。

3 實(shí)際應(yīng)用

3.1 高性能計(jì)算平臺(tái)

圖5 并行程序運(yùn)行時(shí)行為測(cè)量軟件平臺(tái)Fig.5 Software of performance measurement for parallel applications at run time

為了獲取H-CWP-DM診斷模型需要的各種性能數(shù)據(jù)，在某并行機(jī)系統(tǒng)上基于主流性能分析工具形成了可用的并行程序運(yùn)行時(shí)行為測(cè)量軟件平臺(tái)，如圖5所示。該軟件平臺(tái)可用于測(cè)量并行程序在系統(tǒng)上的不同層次、不同方面的性能數(shù)據(jù)，包括性能熱點(diǎn)函數(shù)、計(jì)算時(shí)間、通信時(shí)間及等待時(shí)間等。

所有測(cè)量在一臺(tái)包含1050個(gè)雙路16核計(jì)算節(jié)點(diǎn)的并行機(jī)上進(jìn)行(共33 600個(gè)處理器核)，計(jì)算節(jié)點(diǎn)操作系統(tǒng)使用Linux；處理器為Intel Xeon系列，每顆處理器包含128 MB的共享三級(jí)Cache，內(nèi)存控制器集成在處理器內(nèi)部，配置為NUMA結(jié)構(gòu)，單節(jié)點(diǎn)共享64 GB內(nèi)存。

3.2 MPI并行程序

上述診斷方法目前已應(yīng)用到LARED-S、二維LARED集成、LAP3D等數(shù)十個(gè)實(shí)際生產(chǎn)性數(shù)值模擬程序的性能問題診斷過程中。這些程序都是基于MPI實(shí)現(xiàn)的大規(guī)模并行程序，可以成功擴(kuò)展到上萬處理器核[11]。測(cè)量發(fā)現(xiàn)這些程序都存在通信等待問題，采用上述方法診斷優(yōu)化后，這些程序的性能都提升了15%以上。下面主要以LARED-S程序的性能問題診斷為例，詳細(xì)介紹診斷過程，其他程序的診斷過程類似，這里不再詳述。

3.3 LARED-S程序的性能診斷

根據(jù)第2.2節(jié)給出的通信等待問題的診斷流程，LARED-S程序的性能問題診斷過程如下：

步驟1：測(cè)量并分析程序運(yùn)行時(shí)的性能熱點(diǎn)函數(shù)。LARED-S程序是歐拉網(wǎng)格下的二維、三維并行多介質(zhì)輻射流體力學(xué)模擬程序，主要用于慣性約束聚變等領(lǐng)域中輻射流體界面不穩(wěn)定性模擬[12]。該程序采用960個(gè)進(jìn)程運(yùn)行時(shí)的性能熱點(diǎn)函數(shù)分布如圖6所示。其中，通信時(shí)間占程序執(zhí)行時(shí)間的49.4%，計(jì)算時(shí)間占42.6%。

圖6 LARED-S程序的性能熱點(diǎn)函數(shù)分布Fig.6 Performance hotspots distribution of LARED-S program

步驟2：測(cè)量LARED-S程序中通信等待時(shí)間，確定通信等待時(shí)間對(duì)應(yīng)的同步間隔。測(cè)量發(fā)現(xiàn)MPI_Allreduce通信過程中通信等待時(shí)間占99%。MPI_Allreduce的通信時(shí)間及等待時(shí)間在各進(jìn)程上的分布見圖7，運(yùn)行3個(gè)時(shí)間步的最大等待時(shí)間之和達(dá)125 s，平均每時(shí)間步最大等待時(shí)間達(dá)41.6 s。

圖7 MPI_Allreduce的通信時(shí)間及等待時(shí)間分布Fig.7 Communication time and waiting time distribution of MPI_Allreduce

步驟3：根據(jù)H-CWP-DM診斷模型，定位產(chǎn)生通信等待時(shí)間比較大的關(guān)鍵函數(shù)。根據(jù)式(5)測(cè)量并分析性能數(shù)據(jù)，定位出導(dǎo)致MPI_Allreduce通信等待時(shí)間開銷大的關(guān)鍵函數(shù)如圖8所示。測(cè)量發(fā)現(xiàn)，在一個(gè)時(shí)間步內(nèi)，EOS_Match函數(shù)的EOS_Match_If_970代碼段和EOS_Match_If_946代碼段在聚合通信過程中產(chǎn)生的通信等待時(shí)間較大，二者等待時(shí)間之和為30 s。在一個(gè)時(shí)間步內(nèi)，優(yōu)化前MPI_Allreduce通信過程中產(chǎn)生的通信等待時(shí)間為41.6 s；如果EOS_Match_If_970和EOS_Match_If_946代碼段優(yōu)化負(fù)載平衡算法后， MPI_Allreduce的執(zhí)行時(shí)間最多可減少30 s。由上述數(shù)據(jù)可知，這2個(gè)代碼段改進(jìn)后MPI_Allreduce的等待時(shí)間可縮短72%(30 s/41.6 s)。

圖8 計(jì)算超時(shí)導(dǎo)致的等待時(shí)間Fig.8 Waiting time caused by excess computation

步驟4：分析關(guān)鍵代碼段的詳細(xì)執(zhí)行行為，明確產(chǎn)生通信等待問題的根本原因。找到關(guān)鍵代碼段之后，需要分析EOS_Match函數(shù)的2個(gè)代碼段的詳細(xì)執(zhí)行行為。圖9和圖10分別是代碼段EOS_Match_If_970在不同時(shí)間步(Step)和不同進(jìn)程上的執(zhí)行時(shí)間和執(zhí)行次數(shù)分布。其中，最大執(zhí)行時(shí)間為11 s，平均執(zhí)行時(shí)間為2 s，最小執(zhí)行時(shí)間0 s；最大執(zhí)行次數(shù)為1.3E+06，平均執(zhí)行次數(shù)為3.3E+05，最小執(zhí)行次數(shù)為0。比較圖9、圖10發(fā)現(xiàn)，該代碼段在時(shí)間維度、空間維度的執(zhí)行時(shí)間與執(zhí)行次數(shù)分布特征基本吻合。除此之外，測(cè)量發(fā)現(xiàn)EOS_Match_If_946代碼段也有類似的規(guī)律，這里不再贅述。

(a) Step=0

(b) Step=1

(c) Step=99

(d) Step=100圖9 EOS_Match_If_970代碼段的執(zhí)行時(shí)間分布Fig.9 Execution time distribution of EOS_Match_If_970

(a) Step=0

(b) Step=1

(c) Step=99

(d) Step=100圖10 EOS_Match_If_970代碼段的執(zhí)行次數(shù)分布Fig.10 Visits distribution of EOS_Match_If_970

因此，可推斷代碼段EOS_Match_If_970和EOS_Match_If_946在不同進(jìn)程上的執(zhí)行次數(shù)分布不均衡是導(dǎo)致聚合通信過程出現(xiàn)通信等待問題的根本原因。據(jù)此，開發(fā)人員對(duì)EOS_Match函數(shù)進(jìn)行了2步優(yōu)化：首先根據(jù)物理模擬需求精簡(jiǎn)了該函數(shù)的計(jì)算量，其次通過調(diào)整網(wǎng)格剖分策略實(shí)現(xiàn)相關(guān)代碼段執(zhí)行次數(shù)的均衡分布。優(yōu)化后的LARED-S程序在相同運(yùn)行條件下性能提升32%，MPI_Allreduce的等待時(shí)間縮短44%(18.1s/41.6 s)。

除此之外，本文測(cè)量分析了該程序分別采用CWP-DM診斷模型和H-CWP-DM診斷模型所需的診斷開銷，見表2。相比于CWP-DM診斷模型，采用H-CWP-DM診斷模型所耗費(fèi)的時(shí)間開銷和內(nèi)存開銷都相對(duì)較低。由于測(cè)量所用的并行機(jī)的計(jì)算節(jié)點(diǎn)可用主內(nèi)存為64 GB，而CWP-DM診斷模型單進(jìn)程所需的內(nèi)存開銷高達(dá)115 GB，因此造成該診斷方法失效。

表2 LARED-S程序運(yùn)行3個(gè)時(shí)間步的性能診斷開銷Tab.2 Diagnostic overhead for LARED-S program running in 3 time steps

4 結(jié)論

通過對(duì)現(xiàn)有通信等待問題診斷方法的深入分析，同時(shí)考慮測(cè)量開銷可控、診斷算法誤報(bào)率低的實(shí)際需求，建立了H-CWP-DM診斷模型，并基于該診斷模型總結(jié)出精簡(jiǎn)版、更實(shí)用的通信等待問題診斷方法。將本診斷方法應(yīng)用到LARED-S、二維LARED集成、LAP3D等數(shù)十個(gè)實(shí)際生產(chǎn)性數(shù)值模擬程序的通信等待問題診斷過程。實(shí)際應(yīng)用結(jié)果表明本診斷方法可精確定位導(dǎo)致通信等待問題的關(guān)鍵代碼段，給出的優(yōu)化方案及性能提升空間對(duì)于后續(xù)的程序改進(jìn)具有參考價(jià)值。其中，優(yōu)化后的LARED-S程序性能提升32%，通信等待時(shí)間縮短44%。

除此之外，針對(duì)通信等待問題，未來的研究將立足于下列2個(gè)問題：

1)實(shí)現(xiàn)通信等待問題的自動(dòng)化診斷。將本診斷方法集成到并行程序運(yùn)行時(shí)行為測(cè)量軟件平臺(tái)中，可自動(dòng)生成通信等待問題的診斷報(bào)告，降低人工測(cè)量與分析時(shí)間。

2)將本診斷方法應(yīng)用到更大規(guī)模的MPI并行程序中，甚至是超過百萬核運(yùn)行規(guī)模的應(yīng)用程序。