MPI集合通信性能可擴展性研究與分析*

羅紅兵，張曉霞

北京應用物理與計算數學研究所 高性能計算中心，北京 100094

MPI集合通信性能可擴展性研究與分析*

羅紅兵+，張曉霞

北京應用物理與計算數學研究所 高性能計算中心，北京 100094

集合通信性能是影響并行程序并行效率的重要因素之一，但對于大規模并行計算機上不同類別集合通信的評測和理論分析仍較為缺乏，許多應用程序的通信模塊設計和使用不合理。基于某國產并行機平臺，利用IMB測試程序，對各典型MP（Imessage passing interface）集合通信性能進行了分析，并基于現有通信模型和算法進行理論擬合。結果顯示：不同類別的MPI集合通信操作的性能差異很大，并且許多集合通信的性能在超大規模下與理論差距很大。一方面反映出現有理論和模型的不足；另一方面也體現出，無論是集合通信的優化，還是基于集合通信的特征進行應用程序的通信模塊設計，仍然大有可為。

集合通信；通信性能；可擴展性

1 引言

隨著大規模并行計算機處理器核數的不斷增加，如何開發與并行計算機處理器核數相匹配的并行程序，從而支撐大規模乃至超大規模數值模擬，成為一個備受矚目的重要問題。實際上，在許多成百上千處理器的高性能計算機上，相當數量的工程應用并行軟件，難以獲得理想的絕對計算速度和并行效率，許多并行程序甚至難以獲得正向的加速效果。其中，影響應用程序計算性能發揮的主要瓶頸之一是消息傳遞通信，許多應用程序消息傳遞通信模塊不合理，導致出現全局通信頻率過高，或導致通信堵塞。

要優化并行程序的集合通信性能，首先需要深刻理解集合通信開銷，尤其是通信性能的可擴展性。集合通訊的性能建立在基本的通訊模型基礎上，其中被廣泛使用的通信性能模型是LogP模型[1]，該模型是一個針對分布式存儲的多處理器模型，處理器間采用點對點通信。LogGP（latency，overhead，gap，and processor）模型[2]在LogP模型的基礎上增加了一個參數G，該參數可以描述在傳遞長消息時獲得的帶寬。考慮到集合通信中，隨著消息塊大小的不同，通訊延遲對集合通信性能的影響是不同的，對MPI（message passing interface）集合通信的實現有各種形式的優化[3-8]，如最為經典的是結合二叉樹模型實現bcast和reduce等操作。國內也有一些針對集合通信性能評估和優化方面的研究，包括針對Alltoall通信的測試和優化[9-12]，對集合通信模型的評估[13]。

盡管對于集合通信開銷的評估、優化和理論研究較多，但對于大規模并行計算機上較為全面的集合通信性能分析研究并不多見。不同類別的集合通信性能究竟呈現什么特征？在實際大規模并行機上集合通信的性能是否與相關理論吻合，是否具備了高可擴展性？集合通信理論建模與實測性能間的差距究竟有多大？這些都需要人們對MPI集合通信性能進行全面的定量分析，以期發現大規模并行計算機通信系統運行中的問題，并為大規模并行程序通訊模式的設計提供參考。

2 集合通訊實現算法分析

集合通訊的性能與參與的進程數、消息塊的大小、系統通訊延遲和帶寬相關，同時依賴于集合通訊的實現算法。以下分別對典型的集合通訊性能進行理論分析，其中p為進程數，k為消息的大小，α為通訊延遲，β為通信帶寬的倒數，γ為執行Reduce操作時每字節的計算開銷。

2.1 Bcast和Reduce實現算法

實現Bcast最著名的算法是最小跨距算法（minimum-spanning tree algorithm，MST），其基本思想是把參與通訊的節點等分為兩個無交集的集合，首先從不包含root節點的子集中選取一個目的節點，執行root至該目的節點的一次消息發送；然后分別以root和該目的節點作為root節點，在這兩個子集合中遞歸執行上面的步驟，直至所有節點都收到消息。顯然，MST算法將Bcast和Reduce通信開銷從p降到了lb(p)量級，對于大規模的集合通信，其意義是顯而易見的。

在不考慮網絡沖突的前提下，MST算法的開銷如下：

Reduce與Bcast的實現類似，采用MST算法實現時的開銷如下：

2.2 Scatter和Gather實現算法

Scatter和Gather的實現也可以采用MST算法，其中Gather是Scatter的逆過程，Scatter和Gather的開銷如下：

2.3 Allgather實現算法

Allgather實現算法包括早期的環（ring）方法，其開銷隨進程數p的增加呈線性增長；Allgather實現算法優化的主要思路是減少通訊步數，將時間開銷降低為與進程數p呈對數關系，以減少通信延遲的影響。主要的實現算法有遞歸加倍（recursive doubling）算法和Bruck算法，這些算法的開銷如下：

2.4 Allreduce實現算法

與Allgather的實現類似，Allreduce可以用遞歸加倍（recursive doubling）算法和rabenseifner算法實現，區別在于每個通訊步Allreduce還涉及本地的規約操作，相應的開銷如下：

2.5 Alltoall實現算法

對于短消息（≤256 B），Bruck算法以額外的通訊來換取p的對數級的執行步驟，是當前較好的Alltoall實現算法；對于中等長度的消息（256 B至32 KB之間），irecv-isend算法較好；對長消息，通常采用成對交換（pairwise-exchange）算法，其開銷如下：

3 測試平臺及分析方法

3.1 測試平臺

測試平臺選擇某國產并行機（簡稱BXJ），該系統的每個計算節點包含2顆英特爾微處理器，每顆微處理器包含6個計算核心；互聯系統采用自主設計的高階路由芯片NRC和高速網絡接口芯片NIC，實現光電混合的二層胖樹結構高階路由網絡互連，基本參數如表1。

Table 1 Basic parameters for communication system of BXJ parallel computer表1 BXJ并行機通信系統基本參數

由于該測試平臺處于生產性運行狀態，測試時沒有機會占用全系統，文中相關測試的最大并行規模為8 192個MPI進程。

3.2 測試和分析方法

對于MPI各種集合通信性能的理論值，依據上文的相應算法進行計算。通訊延遲α和通信帶寬β依據系統基本通訊的實際測試值設為固定值，為簡便起見，不考慮這些參數隨通訊距離、消息塊大小的變化；γ參數依據微處理器的主頻、SIMD位數等估算，不考慮操作的訪存開銷。

對于MPI集合通信的性能測試，選用Intel IMB測試程序，評測的集合通訊操作主要包括Reduce、Gather、Alltoall、Bcast、Scatter、Allgather和Allreduce。測試結果取多次測試的均值。

4 基本通訊參數測試與數據分析

首先，利用IMB中PingPong程序和Sendrecv程序測試MPI通訊延遲和傳輸帶寬情況。

表2結果顯示：（1）BXJ的最小延遲2.72 μs與系統提供的參數2.37 μs基本相當，但PingPong的數據量超過一個數據包64 Byte（packet）時，延遲顯著上升。顯然在BXJ處于生產性運行時，測試程序明顯與其他程序存在通訊通道的競爭。（2）單進程MPI通訊帶寬隨消息塊尺寸的增加而不斷增加，但單MPI進程很難達到最大通訊帶寬，即便傳輸MB量級的消息。

Table 2 Results of PingPong表2 PingPong測試結果

表3和表4分別是每個計算節點執行8個進程和12個進程時，Sendrecv程序運行8 192個進程時的延遲和帶寬情況。

Table 3 Results of Sendrecv（8 processes per node）表3 Sendrecv測試結果（單節點8進程）

Table 4 Results of Sendrecv(12 processes per node)表4 Sendrecv測試結果（單節點12進程）

表3和表4測試結果顯示：（1）上述兩種執行方式下Sendrecv的平均最小延遲基本都在3.20 μs左右，考慮到Sendrecv包含send和receive操作各一次，8 192個進程執行時的延遲基本與BXJ的通訊參數相符。（2）每個計算節點執行8個進程時，每個進程可以獲得的帶寬為656.54 MB/s，即單計算節點可獲得的通訊帶寬為8×656.54 MB/s=5 252.32 MB/s；每個計算節點執行12個進程時，每個進程可以獲得的帶寬為450.74 MB/s，即該節點可獲得的通訊帶寬為8× 450.74 MB/s=5 408.88 MB/s。（3）以α-β模型估算，Sendrecv操作傳輸64 KB數據包的延遲在141.86 μs至280.52 μs之間（12進程/單節點），分別針對send和receive完成可以重疊及完全沒有重疊，與實測數據基本吻合；Sendrecv操作傳輸64 KB數據包的延遲在98.40 μs至193.60 μs之間（8進程/單節點），與實測數據也基本吻合。

5 典型全局通信性能的測試與評估

5.1 Bcast性能測試與分析

依據當前Bcast實現算法，其開銷與MPI進程數、數據量、MPI通訊延遲和帶寬有關，其中與MPI進程數呈對數關系，與傳輸的數據量、MPI通訊延遲和通訊帶寬則分別呈正比。圖1、圖2分別是16個MPI進程至8 192個MPI進程下，對128 B和16 KB的消息執行Bcast操作的通訊延遲情況，即固定消息塊大小，測試隨MPI進程數增長時的Bcast通訊延遲變化情況。其中實測值有兩組，分別是每個計算節點啟動8個MPI進程和12個MPI進程的結果。對于理論值，基于MST算法進行了估算，其中的系統通訊最小延遲α取2.37 μs，β根據PingPong時的通信帶寬3 183 MB/s換算。

圖1的測試數據顯示：（1）對于128 B消息，Bcast通訊延遲的實測值與MST算法的理論值吻合得較好，無論是每個計算節點啟動8個MPI進程，還是啟動12個MPI進程，Bcast通訊延遲的實測值與MST算法的理論值相差不大。（2）由于計算節點啟動12個MPI進程時，通訊帶寬競爭比啟動8個MPI進程時更大，相應地Bcast通訊延遲就略大一些。（3）由于實際系統不是獨占的系統，實際運行時的通訊延遲和帶寬有一定的波動，實測值也存在一定的波動。

圖2顯示：（1）對于16 KB的消息，Bcast通訊延遲的實測值的變化趨勢在MPI進程數不大于4 096時與理論值的趨勢基本一致，實測值與MST算法的理論值相差較大，這主要是源自該通訊規模下理論值的通訊帶寬與MPI實際通訊帶寬偏差較大。（2）當MPI進程數達到8 192時，Bcast通訊延遲發生了突變，達到了4 096進程時的2倍以上，原因很難解釋。

Fig.1 Latency of Bcast for different MPI processes(128 B message)圖1 Bcast開銷與MPI進程數的關系（128 B消息塊）

Fig.2 Latency of Bcast for different MPI processes(16 KB message)圖2 Bcast開銷與MPI進程數的關系（16 KB消息塊）

5.2 Reduce性能測試與分析

Reduce開銷除了與參與的MPI進程數、傳輸的數據量、MPI通訊延遲和通訊帶寬有關，還與Reduce運算的性能有關。由于運算的性能遠高于通訊性能，起主導性的仍是通訊延遲和通訊帶寬。圖3、圖4分別是16個MPI進程至8 192個MPI進程下，對128 B和16 KB的消息執行Reduce操作的通訊延遲情況。Reduce理論值同樣基于MST算法估算，延遲α和β取值同Bcast。對于γ，以主頻2.2 GHz計算，并假定每個時鐘周期可以執行256位計算。

Fig.3 Latency of Reduce for different MPI processes(128 B message)圖3 Reduce開銷與MPI進程數的關系（128 B消息塊）

Fig.4 Latency of Reduce for different MPI processes(16 KB message)圖4 Reduce開銷與MPI進程數的關系（16 KB消息塊）

圖3 、圖4的測試數據顯示：（1）Reduce的實測性能與理論性能有較大差距，其直接原因是實際操作所能獲得的系統通訊帶寬低于理論估計。（2）計算節點啟動8個MPI進程和12個MPI進程時，Reduce的延遲差別不大，表明制約Reduce操作性能的瓶頸主要不是節點內進程對通訊帶寬的競爭。（3）Reduce操作在4 096進程時發生了性能抖動，反映出通訊系統性能波動對Reduce性能的影響。

5.3 Gather性能

Gather實測值和理論值見圖5、圖6。實測值分別是16個MPI進程至8 192個MPI進程下，對128 B和18 KB的消息執行Gather操作的通訊延遲情況，包含每個計算節點啟動8個MPI進程和12個MPI進程的結果。理論值基于2.2節式（4）計算，系統通訊最小延遲α和β取值同Bcast。

圖5、圖6的測試數據顯示：（1）Gather通訊延遲的實測值與MST算法的理論值吻合得較好，無論是計算節點啟動8個MPI進程，還是啟動12個MPI進程，Gather延遲的實測值與理論值相差不大。（2）總體上看，計算節點啟動的進程數與Gather通信延遲的關系不大，計算節點啟動12個MPI進程時的Gather通訊延遲略大一些。

Fig.5 Latency of Gather for different MPI processes(128 B message)圖5 Gathert開銷與MPI進程數的關系（128 B消息塊）

Fig.6 Latency of Gather for different MPI processes(16 KB message)圖6 Gathert開銷與MPI進程數的關系（16 KB消息塊）

5.4 Scatter性能

圖7、圖8分別是16個MPI進程至8 192個MPI進程下，對128 B和16 KB的消息執行Scatter操作的通訊延遲情況。其中實測值有兩組，分別是每個計算節點啟動8個MPI進程和12個MPI進程的結果。Scatter操作的理論值基于2.2節的式（3）估算，α和β取值同Bcast。

圖7、圖8的測試數據顯示：（1）當消息塊大小為128 B時，Scatter通訊延遲的實測值與MST算法的理論值吻合得較好，無論計算節點啟動8個MPI進程，還是啟動12個MPI進程，Scatter通訊延遲的實測值與理論值相差不大。（2）對于16 KB的消息，Scatter通訊延遲的實測值在進程數小于等于512時與理論值基本一致，當MPI進程數超過1 024之后，則明顯大于理論值。（3）計算節點啟動的MPI進程數對Scatter操作的延遲情況影響不大，計算節點啟動12個MPI進程時，通訊延遲略大一些。

Fig.7 Latency of Scatter for different MPI processes(128 B message)圖7 Scatter開銷與MPI進程數的關系（128 B消息塊）

Fig.8 Latency of Scatter for different MPI processes(16 KB message)圖8 Scatter開銷與MPI進程數的關系（16 KB消息塊）

5.5 Allgather性能

Allgather與Gather類似，區別是所有進程同時收集數據，也相當于任一進程先調一次Gather，然后再對收集的數據進行一次Bcast。對Allgather操作的性能進行理論估算時，采用2.3節的式（5）和式（7）（本文僅考慮進程數為2的冪的情況）。對于α和β，考慮到Allgather操作過程中，各進程同時在做大量的發送和接收操作，對通訊帶寬的競爭明顯，理論分析時的傳輸帶寬以Sendrecv時實測值為基準，12進程/單節點時傳輸帶寬為450 MB/s，8進程/單節點時傳輸帶寬為569 MB/s。圖9～圖12是測試結果。

圖9～圖12的結果顯示：（1）消息塊為16 KB時，Allgather性能變化趨勢與ring算法和bruck算法的理論值基本一致，但隨著進程數的增加，Allgather的實測值與理論值的差距逐步增大。（2）消息塊為128 B時，Allgather的實測值在進程數為2 048以內時與理論值很接近，大于bruck算法的理論值，小于ring算法的理論值，反映出bruck算法對于短消息的優勢；但是，當進程數為4 096和8 192時，Allgather的實測值急劇增加，原因很難準確估計。考慮到每個計算節點啟動8個MPI進程或12個MPI進程都出現這一情況，可以將這一情況視作必然出現或很容易出現。

5.6 Allreduce性能

Allreduce與Reduce類似，區別是所有進程同時做規約，也相當于任一進程先調一次Reduce，然后再對收集的數據進行一次Bcast。對Allreduce操作的性能進行理論估算時，采用2.4節的式（8）和式（9）。對于α和β，取值與Allgather理論性能估算類似一致。對于γ，與Reduce操作的理論估算一樣，以主頻2.2 GHz計算，并假定每個時鐘周期可以執行256位計算。圖13～圖16是128 B和16 KB的消息塊Allreduce操作的通訊延遲隨MPI進程數增長的變化情況，及與理論值的對比。

圖13～圖16的結果顯示：（1）消息塊為16 KB時，無論是每個計算節點啟動8個MPI進程，還是每個計算節點啟動12個MPI進程，Allreduce性能變化趨勢與理論值基本一致，但當進程數為4 096或8 192時，Allreduce實測值有時會急劇增加，與理論值的差距增大。（2）消息塊為128 B時，Allreduce的實測值與理論值很接近，盡管實測值隨進程數的增加，與理論值的差距略微增加。

Fig.9 Latency ofAllgather for different MPI processes (16 KB message,8 processes per node)圖9 Allgather開銷與MPI進程數的關系（16 KB消息塊，單節點運行8個MPI進程）

Fig.11 Latency ofAllgather for different MPI processes (128 B message,8 processes per node)圖11 Allgather開銷與MPI進程數的關系（128 B消息塊，單節點運行8個MPI進程）

Fig.12 Latency ofAllgather for different MPI processes (128 B message,12 processes per node)圖12 Allgathert開銷與MPI進程數的關系（128 B消息塊，單節點運行12個MPI進程）

Fig.13 Latency ofAllreduce for different MPI processes (16 KB message,12 processes per node)圖13 Allreduce開銷與MPI進程數的關系（16 KB消息塊，單節點運行12個MPI進程）

Fig.14 Latency ofAllreduce for different MPI processes (16 KB message,8 processes per node)圖14 Allreduce開銷與MPI進程數的關系（16 KB消息塊，單節點運行8個MPI進程）

Fig.15 Latency ofAllreduce for different MPI processes (128 B message,12 processes per node)圖15 Allreduce開銷與MPI進程數的關系（128 B消息塊，單節點運行12個MPI進程）

Fig.16 Latency ofAllreduce for different MPI processes (128 B message,8 processes per node)圖16 Allreduce開銷與MPI進程數的關系（128 B消息塊，單節點運行8個MPI進程）

5.7 Alltoall性能

Alltoall需要所有的進程參與，且每個進程發送和接收消息塊尺寸乘以進程數的消息量。對Alltoall操作的性能進行理論估算時，采用2.5節的式（10）和式（11），傳輸帶寬以Sendrecv時實測值為基準，12進程/單節點時傳輸帶寬為450 MB/s，8進程/單節點時傳輸帶寬為569 MB/s。圖17～圖20分別是128 B和16 KB的消息塊Alltoall操作的通訊延遲隨MPI進程數增長的變化情況，及與理論值的對比。

圖17～圖20的結果顯示：（1）對于16 KB的消息塊，Alltoall性能在MPI進程數小于2 048時，變化趨勢與理論值基本一致，但當進程數為4 096或8 192時，Alltoall實測值有時會急劇增加，尤其是8 192個MPI進程。（2）消息塊為128 B時，Alltoall的實測值與理論值很接近，在每個計算節點啟動12個MPI進程的測試中，測試值在long算法和bruck算法的理論值之間，表明系統對于該規模的消息塊實際采用的肯定不是long算法，而是bruck算法。（3）Alltoall實際性能的波動很大，明顯比其他類別集合通訊的性能波動大。

5.8 典型全局通信性能對比分析

為便于更好地理解Reduce、Gather、Alltoall、Bcast、Scatter、Allgather和Allreduce等全局通信的性能，以下固定全局通信過程中的消息長度，對比并評估上述全局通信的延遲情況。表5是消息長度為16 KB時使用8 192個MPI進程執行上述全局通訊操作在BXJ上的執行延遲情況。表5中數據顯示：（1）不同類別的MPI全局通訊操作具有不同的延遲情況，從數百微秒到數百毫秒，直至數秒；（2）在Reduce、Gather、Bcast、Scatter這些單邊集合通訊中，Reduce操作延遲最小；（3）對于Alltoall、Allgather和Allreduce操作，Allreduce延遲最小。

Fig.17 Latency ofAlltoall for different MPI processes (16 KB message,12 processes per node)圖17 Alltoall開銷與MPI進程數的關系（16 KB消息塊，單節點運行12個MPI進程）

Fig.18 Latency ofAlltoall for different MPI processes (16 KB message,8 processes per node)圖18 Alltoall開銷與MPI進程數的關系（16 KB消息塊，單節點運行8個MPI進程）

Fig.19 Latency ofAlltoall for different MPI processes (128 B message,12 processes per node)圖19 Alltoall開銷與MPI進程數的關系（128 B消息塊，單節點運行12個MPI進程）

Fig.20 Latency ofAlltoall for different MPI processes (128 B message,8 processes per node)圖20 Alltoall開銷與MPI進程數的關系(128 B消息塊，單節點運行8個MPI進程)

Table 5 Latency of collective communications表5 典型全局通訊操作延遲情況

6 小結

以上測試和分析，反映出大規模并行計算機上集合通信性能的如下特點：（1）不同類別的MPI集合通信操作具有差別極大的延遲情況，尤其在大規模情況下，許多全局通信操作的延遲往往以超線性的速度增加。（2）消息塊的大小對于MPI集合通信的性能影響很大，即便是性能較好的Bcast操作的延遲，在大消息塊的情況下也會呈超線性增長。

除了以上在并行程序通信模式設計時需要予以重視的集合通信性能特征之外，還有以下問題：（1）現有的模型對Reduce等單邊集合通信操作的理論建模基本準確，但大規模情況下仍需進一步完善。（2）對Alltoall等多對多集合通信性能的理論建模是值得深入研究的問題，尤其在超大規模情況下，理論值與實際值差距很大，且缺乏理論模型方面的解釋。

References:

[1]Culler D E,Karp R M,Patterson D,et al.LogP:a practical model of parallel computation[J].Communications of the ACM,1996,39(11):78-85.

[2]Alexanddrov A,Ionescu M F,Schauser K E,et al.LogGP: incorporating long messages into the LogP model—one step closer towards a realistic model for parallel computation [C]//Proceedings of the 7th Annual ACM Symposium on Parallel Algorithms and Architectures,Santa Barbara,USA, Jun 24-26,1995.New York:ACM,1995:95-105.

[3]Chan E,Heimlich M,Purkayastha A,et al.Collective communication:theory,practice,and experience[J].Concurrency and Computation:Practice&Experience,2007,19(13):1749-1783.

[4]Thakur R,Rabenseifner R,Gropp W.Optimization of collective communication operations in MPICH[J].International Journal of High Performance Computing Applications,2005,19(1):49-66.

[5]Kielmann T,Hofman R F H,Bal H E,et al.MAGPIE:MPI’s collective communication operations for clustered wide area systems[C]//Proceedings of the 7th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, Atlanta,USA,May 4-6,1999.NewYork:ACM,1999:131-140. [6]Bruck J,Ho C-T,Kipnis S,et al.Efficient algorithms for allto-all communications in multiport message-passing systems[J].IEEE Transactions on Parallel and Distributed Systems,1997,8(11):1143-1156.

[7]Chan E W,Heimlich M F,Purkayastha A,et al.On optimizing collective communication[C]//Proceedings of the 2004 IEEE International Conference on Cluster Computing,San Diego, USA,Sep 20-23,2004.Washington:IEEE Computer Society, 2004:145-155.

[8]Kumar R,Mamidala A R,Panda D K.Scaling alltoall collective on multicore systems[C]//Proceedings the 2008 IEEE International Symposium on Parallel and Distributed Processing,Miami,USA,Apr 14-18,2008.Piscataway,USA: IEEE,2008:1-8.

[9]Rao Li,Zhang Yunquan,Li Yuchneg.Performance test and analysis of alltoall collective communication on domestic hundred trillion cluster system[J].Computer Science,2010, 37(8):186-188.

[10]Li Qiang,Sun Ninghui,Huo Zhigang,et al.Optimizing MPI alltoall communications in multicore cluster[J].Journal of Computer Research and Development,2013,50(8): 1744-1754.

[11]Zhang Panyong,Meng Dan,Huo Zhigang.Research of collectives optimization on modern multicore clusters[J].Chinese Journal of Computers,2010,33(2):317-324.

[12]Chen Jing,Zhang Yunquan,Zhang Linbo,et al.A new MPI allgather algorithm and implement[J].Chinese Journal of Computers,2006,29(5):808-814.

[13]Liu Yang,Cao Jianwen,Li Yucheng.Testing and analyzing of collective communication models[J].Computer Engineering andApplications,2006,42(6):30-33.

附中文參考文獻：

[9]饒立,張云泉,李玉成.國產百萬億次機群系統Alltoall性能測試與分析[J].計算機科學,2010,37(8):186-188.

[10]李強,孫凝暉,霍志剛,等.MPI Alltoall通信在多核機群中的優化[J].計算機研究與發展,2013,50(8):1744-1754.

[11]張攀勇,孟丹,霍志剛.多核環境下高效集合通信關鍵技術研究[J].計算機學報,2010,33(2):317-324.

[12]陳靖,張云泉,張林波,等.一種新的MPI Allgather算法及其在萬億次機群系統上的實現與性能優化[J].計算機學報,2006,29(5):808-814.

[13]劉洋,曹建文,李玉成.聚合通信模型的測試與分析[J].計算機工程與應用,2006,42(6):30-33.

LUO Hongbing was born in 1968.He received the M.S.degree in computer software from Huazhong University of Science and Technology in 1992.Now he is a professor at Institute of Applied Physics and Computational Mathematics.His research interests include parallel computing and performance optimization,etc.

羅紅兵（1968—），男，江西永新人，1992年于華中科技大學獲得碩士學位，現為北京應用物理與計算數學研究所研究員，主要研究領域為高性能計算，性能優化等。發表學術論文20余篇，承擔國家863計劃等項目。

ZHANG Xiaoxia was born in 1973.She received the M.S.degree in computer system from National University of Defense Technology in 1998.Now she is a senior engineer at Institute of Applied Physics and Computational Mathematics.Her research interests include parallel computing and performance evaluation,etc.

張曉霞（1973—），女，河南焦作人，1998年于國防科學技術大學獲得碩士學位，現為北京應用物理與計算數學研究所高級工程師，主要研究領域為并行計算，性能評測等。

Analysis of Scalability for MPI Collective Communication*

LUO Hongbing+,ZHANG Xiaoxia
High Performance Computing Center,Institute of Applied Physics and Computational Mathematics,Beijing 100094, China
+Corresponding author:E-mail:hbluo@iapcm.ac.cn

The performance of collective communications impacts the efficiency of large scale parallel numerical computing application.Since the theoretic analysis and evaluation on every type of collective communications is still insufficient for the programmer,the communication modules of many applications are designed and used unreasonably.Using Intel IMB benchmark,this paper analyzes and evaluates the typical MPI(message passing interface) collective communication on BXJ supercomputer(a parallel machine platform),and gives the theoretic results based on the current model and algorithm.The results show that the performance of different MPI collective communications is different.There is an obvious gap between the actual value of some collective communication and theoretic value.The results reflect that there are still many researches,such as accurate theoretic performance model for some collective communication,optimization of collective communication,and optimization of application communication module,etc.

collective communication;communication performance;scalability

10.3778/j.issn.1673-9418.1512057

A

TP311

*The National High Technology Research and Development Program of China under Grant No.2014AA01A302(國家高技術研究發展計劃(863計劃)).

Received 2015-12,Accepted 2016-02.

CNKI網絡優先出版:2016-02-03,http://www.cnki.net/kcms/detail/11.5602.TP.20160203.1126.010.html

LUO Hongbing,ZHANG Xiaoxia.Analysis of scalability for MPI collective communication.Journal of Frontiers of Computer Science and Technology,2017,11(2)：252-261.