劉 康，萬 偉，劉 波，李俊宏，李 柱

（鄭州大學 計算機與人工智能學院，鄭州 450001）

0 概述

“嵩山”超級計算機部署于國家超級計算鄭州中心，是我國國產(chǎn)自研的新一代超高性能計算平臺，它采用32 核CPU+國產(chǎn)加速器的異構(gòu)計算架構(gòu)、InfiniBand（直譯為“無限帶寬”技術(shù)，縮寫為IB）［1-2］超高速網(wǎng)絡以及高性能分布式并行存儲系統(tǒng)，理論峰值算力可達100 PFlops，整機實測性能達到65 PFlops。InfiniBand 是一個用于高性能計算平臺的計算機網(wǎng)絡通信標準，具有極高的吞吐量和極低的延遲，用于計算機與計算機之間的數(shù)據(jù)互連，也用作服務器與存儲的互連以及存儲系統(tǒng)之間的互連。InfiniBand搭載的Mellanox ConnectX-6 網(wǎng)卡提供了最高200 Gb/s帶寬的數(shù)據(jù)傳輸性能。

“嵩山”計算平臺所搭載的主要通信框架為UCX（Unified Communication X）［3-4］。UCX 作為底層InfiniBand 網(wǎng)絡和上層并行編程模型的通信中間件，定義了一組統(tǒng)一的標準化通信編程接口，以滿足主流的并行編程模型，如MPI（Message Passing Interface）［5］、UPC（Unified Parallel C）［6］、PGAS（Partitioned Global Address Space）［7］等的需求，同時又可以在各種高性能平臺上實現(xiàn)，以便在互聯(lián)網(wǎng)絡上更好地滿足高性能、可移植、可伸縮等并行應用的開發(fā)需求［8-10］。

但是，由于RDMA（Remote Direct Memory Access）系統(tǒng)具有復雜性，因此存在很多未知的問題［11-12］，UCX 作為“嵩山”RDMA 系統(tǒng)中的通信框架，在“嵩山”特色互聯(lián)網(wǎng)絡架構(gòu)上還有一定的優(yōu)化空間。在存在復雜通信環(huán)境的集合通信中，通信有時會成為瓶頸而拖累了整體計算速度。UCX 的通信性能直接影響了上層并行編程模型的數(shù)據(jù)傳輸與計算性能。因此，在“嵩山”超級計算平臺上對UCX 進行研究與優(yōu)化具有重要的工程意義。

本文基于“嵩山”超級計算平臺，以MPI 為例，使用osu_benchmark 測試工具［13］在不同的傳輸下進行多種集合通信測試，獲得各種情形下的延遲與帶寬數(shù)據(jù)，以發(fā)現(xiàn)節(jié)點設備存在的瓶頸。同時，對UCX的代碼進行優(yōu)化，以解決節(jié)點內(nèi)通信占用網(wǎng)卡資源的問題。在此基礎(chǔ)上，實現(xiàn)UCX 在“嵩山”超級計算平臺上的最優(yōu)傳輸選擇，以提升平臺的集合通信能力以及整體的計算性能。

1 “嵩山”超級計算機互聯(lián)網(wǎng)絡

1.1 InfiniBand 互聯(lián)網(wǎng)絡

InfiniBand 是一種高速互聯(lián)網(wǎng)絡，用于連接大型集群和超級計算機，它是目前應用最廣泛的高速互連網(wǎng)絡之一，2016 年在Top500 互連網(wǎng)絡中就已經(jīng)達到37.5%的份額［14］。InfiniBand 網(wǎng)絡為通信提供了雙邊（發(fā)送-接收）和單邊（RDMA）語義。InfiniBand上的通信使用隊列對（QP）模型，其中，發(fā)送和接收隊列分別用于發(fā)送和接收消息，工作請求被提交到這些隊列中，硬件可以在隊列中讀取工作請求以執(zhí)行通信。此外，將隊列與每個QP 相關(guān)聯(lián)，用于通知通信完成。在通過InfiniBand 進行通信時，需要注意注冊硬件訪問的所有內(nèi)存區(qū)域。為了減少內(nèi)存注冊的開銷，短消息（Short）可以內(nèi)聯(lián)到工作請求中，而較大的消息可以利用零拷貝（ZCopy）協(xié)議。這種策略意味著工作請求只獲取內(nèi)存緩沖區(qū)的描述信息，然后直接從緩沖區(qū)讀取數(shù)據(jù)，而不需要CPU 的參與。

當前InfiniBand 結(jié)構(gòu)實現(xiàn)了各種傳輸機制［15-16］，最常見的是RC（面向連接的可靠連接）和UD（無連接的不可靠數(shù)據(jù)報），后者只實現(xiàn)了雙邊通信語義。此外，UD 一次只能傳輸一個MTU 的數(shù)據(jù)（通常是4 KB），而RC 通常能提供比UD 更高的帶寬和更低的延遲，代價是RC 對資源有很高的要求：要完全連接N個進程；要求每個進程有O（N2）個連接和O（N）個隊列對。而UD 是無連接的，因此，每個進程只需要一個UD 隊列對。為了減少RC 的內(nèi)存消耗，InfiniBand 規(guī)范引入了共享接受隊列以及擴展的RC傳輸。Mellanox 后續(xù)又推出了動態(tài)連接（DC）傳輸服務［17］，該服務動態(tài)地創(chuàng)建和銷毀連接，將內(nèi)存消耗限制在接近UD 的級別，同時提供與RC 類似的內(nèi)存語義。然而，DC 的可擴展性設計是以性能為代價的，主要是因為存在連接事務的開銷［18］。

InfiniBand 的用戶 空間接口是Verbs API［19］，它是一個帶有OFED 堆棧的用戶級別的庫，位于內(nèi)核級Verbs API 之上。內(nèi)核API 與特定供應商的InfiniBand 驅(qū)動程序和驅(qū)動程序庫協(xié)作，以實現(xiàn)InfiniBand 硬件訪問。InfiniBand 軟件棧示意圖如圖1 所示。

圖1 InfiniBand 軟件棧和UCXFig.1 InfiniBand software stack and UCX

1.2 Socket Direct 技術(shù)

隨著數(shù)據(jù)量的指數(shù)級增長，使用者對服務器和計算資源提出了更高的性能要求，以便對海量數(shù)據(jù)進行實時分析?！搬陨健背売嬎闫脚_采用非均勻內(nèi)存訪問（NUMA）架構(gòu)［20］，每個處理器擁有4 個CPU Die，在每個Die 內(nèi)集成了8 個物理核心，共計32 個物理核心。

在一般情況下，數(shù)據(jù)主要依靠GMI 總線來進行跨Die 傳輸，如圖2（a）所示，此時Die3/Die4 中的數(shù)據(jù)如果要傳輸至網(wǎng)卡，則網(wǎng)絡流量需要使用GMI 總線經(jīng)過Die0/Die1 然后再流入網(wǎng)卡。而“嵩山”平臺的網(wǎng)絡架構(gòu)支持Socket Direct 技術(shù)，該技術(shù)可以使節(jié)點中的每個Die（NUMA node）都可以通過其專用的PCIe 接口直接連接到網(wǎng)絡，使得網(wǎng)絡流量無須遍歷內(nèi)部總線（GMI）和其他Die，如圖2（b）所示。Socket Direct 不僅降低了CPU 的利用率、增加了網(wǎng)絡吞吐量，還顯著降低了開銷與延遲，從而提高了服務器的性能。

圖2 跨Die 傳輸?shù)膶Ρ菷ig.2 Comparison of cross-Die transmission

1.3 UCX 設計

隨著DPU 的普及以及各類DSA 芯片的廣泛使用［21］，如何在這之上抽象出統(tǒng)一的內(nèi)存訪問語義和統(tǒng)一的通信方式成為一個值得研究的問題，因此，UCX 應運而生。UCX 可以在通信方面實現(xiàn)低級別的軟件開銷，并且提供接近原生級別的性能。UCX旨在提供一個統(tǒng)一的抽象通信接口，能夠適配任何通信設備，并支持各種應用的需求，從而滿足當前高性能、可移植且穩(wěn)定可靠的并行應用開發(fā)需求，同時還能通過持續(xù)的迭代更新來適應未來的高速互聯(lián)網(wǎng)絡。

從圖1 可以看出UCX 軟件堆棧是如何放置在InfiniBand 之上的，UCX 由下層UCT 和上層UCP 這2 層組成。下文將介紹UCX 框架，討論UCP 和UCT這2 個層之間的主要區(qū)別以及UCX 內(nèi)部最重要的語義。

1.3.1 UCX 框架

UCX 利用高速網(wǎng)絡進行節(jié)點間通信，并利用共享內(nèi)存機制進行有效的節(jié)點內(nèi)通信。UCX 總體采用分層結(jié)構(gòu)公開一組抽象通信原語，這些原語充分利用了可用的硬件資源和負載，其中包括RDMA［22-23］（InfiniBand 和RoCE）、TCP、共享內(nèi)存和網(wǎng)絡原子操作。圖3 顯示了UCX 的軟件棧結(jié)構(gòu)。

圖3 UCX 軟件棧結(jié)構(gòu)Fig.3 UCX software stack structure

UCX 通過提供高級API 促進快速開發(fā)，屏蔽低層細節(jié)，同時保持高性能和可伸縮性，其框架主要由3 個組件組成，即UCS（UC-Services）、UCT（UCTransports）和UCP（UC-Protocols）。每一 個組件都導出一個公共API，可以作為一個獨立的庫使用。底層的UCT 適配各種通信設備，上層的UCP 則是在UCT 不同設備的基礎(chǔ)上封裝更抽象的通信接口，以方便使用。

UCT 是傳輸層，它抽象了各種硬件架構(gòu)之間的差異，并提供了一個支持通信協(xié)議實現(xiàn)的低級API，從單機的共享內(nèi)存到常用的TCP Socket 以及“嵩山”超算底層的InfiniBand 協(xié)議，都有很好的支持。該層的主要目標是提供對硬件網(wǎng)絡功能的直接有效訪問，為此，UCT 依賴供應商提供的低級驅(qū)動程序，如InfiniBand Verbs、Cray 的uGNI 等。此外，該層還提供用于通信上下文管理（基于線程和應用程序級別）以及分配和管理的構(gòu)造。在通信API 方面，UCT 定義了立即（short）、緩沖復制、發(fā)送（BCopy）和零拷貝（ZCopy）等通信操作的接口。

UCP 是協(xié)議層，通過使用UCT 層公開的較低級別功能來實現(xiàn)上層高級編程模型（如MPI、UPC、PGAS）所使用的較高級別協(xié)議。UCP 提供的功能是能夠為通信選擇不同的傳輸、消息分段、多軌通信以及初始化和完成庫。目前，API 具有的接口類別包括初始化、遠程內(nèi)存訪問（RMA）通信、原子內(nèi)存操作（AMO）、活動消息（Active Message）、標簽匹配（Tag-Matching）和集合（Collectives）。

1.3.2 UCX 語義

UCX 提供的最主要語義包括通信上下文、通信原語、通信實體和連接建立。這4 種語義詳細敘述如下：

1）通信上下文。UCP 和UCT 的最主要區(qū)別在于通信上下文。UCT 被設計成一個位于單個通信設備和傳輸層之上的通信層，而UCP 可以讓用戶操作不同的設備和傳輸層。因此，UCT 在設備（如InfiniBand、共享內(nèi)存SM）上定義了一個內(nèi)存域，用來分配和注冊進行通信的內(nèi)存以及特定設備（如InfiniBand 上的UD 和RC）上的特定傳輸接口。內(nèi)存域和接口都有一組它們自己的屬性，這些屬性來自于硬件功能。內(nèi)存域?qū)傩园▋?nèi)存分配限制和內(nèi)存訪問的憑據(jù)，接口屬性包括傳輸機制的通信和連接能力以及協(xié)議切換的閾值。UCP 將這些多個UCT內(nèi)存域和接口封裝在單個通信上下文中，并根據(jù)硬件屬性和性能指標選擇適合通信操作的接口。

3）通信實體。Worker 是UCX、UCP 和UCT 的核心通信實體。Worker 的主要特征是有自己的進度引擎（progress engine），進度引擎會在所有打開的接口上強制執(zhí)行當前的進度。在Worker 要啟用與另一個進程的通信時，每個進程都會創(chuàng)建一個端點（endpoint），并將其連接到遠程進程的endpoint。UCT endpoint 與特定接口（如UD、RC）綁定，即每個使用的接口對應一個UCT endpoint，而UCP endpoint擁有多個UCT endpoint。因此，在UCP 中，endpoint始終連接著2 個Worker。在內(nèi)部，UCP 負責從可用于執(zhí)行通信操作的接口/UCT endpoint 中選擇最佳的接口/UCT endpoint。

4）連接建立。當UCP 的Worker 創(chuàng)建endpoint時，UCP 層為每種類型的操作選擇一個或多個接口，并且在每個接口上創(chuàng)建并對應一個UCT endpoint，所有的這些UCT endpoint 都與父UCP endpoint 相關(guān)聯(lián)。如果一個接口對應無連接的傳輸，那么它可以立即連接到遠程接口，這也就是UCP 中發(fā)生的情況，即UCT endpoint 通過無連接傳輸立即建立連接。但是，如果接口對應P2P 的傳輸，UCP 將創(chuàng)建一個stub endpoint。Wireup UCT endpoint 始終是無連接的，通過立即發(fā)送Wireup 請求然后通過P2P 傳輸以實現(xiàn)所有UCT endpoint 的連接。當父UCP endpoint 的所有UCT endpoint 都已連接時，stub endpoint 即被銷 毀。

2 UCX 在“嵩山”中的優(yōu)化

2.1 參數(shù)調(diào)優(yōu)

UCX 可以適配多種設備、系統(tǒng)、架構(gòu)等，因而具有繁雜的參數(shù)設置，調(diào)整各項參數(shù)可以使UCX 更加適配“嵩山”平臺。

“嵩山”平臺的高速網(wǎng)絡使用Socket Direct技術(shù)劃分CPU 為4 個NUMA nodes 并分別連接至4 塊網(wǎng)卡設備，實現(xiàn)各個Die 與網(wǎng)卡的直連。在UCX 中設置UCX_MAX_RNDV_LANES 為4，為Rendezvous 協(xié) 議開啟4 端口的多軌傳輸，使用多塊網(wǎng)卡同時進行傳輸，從而提升數(shù)據(jù)的傳輸效率。

“嵩山”平臺CPU 使用的NUMA 架構(gòu)，在PCIe總線傳輸中更適合采用寬松排序（relaxed order）的事務排序方法，即允許PCIe 交換開關(guān)，將軟件確認過的事務重排在其他事務之前發(fā)送，這樣既提升了PCIe 總線效率，又能保證程序如期執(zhí)行。本文使用UCX_IB_PCI_RELAXED_ORDERING=on 在UCX 中開啟寬松排序，使得所有使用UCX 通信庫的程序采用寬松排序，從而獲得更高的性能。

2.2 網(wǎng)卡占用優(yōu)化

在使用UCX 進行節(jié)點內(nèi)部通信時，進程間通信不僅會使用共享內(nèi)存?zhèn)鬏?，還會調(diào)用網(wǎng)卡設備共同完成數(shù)據(jù)傳輸，這是由于ITIGIN［4］為UCX 添加了實現(xiàn)，即進行進程間通信時rc 會輔助共享通信，從而共同完成通信。但是在“嵩山”平臺上，實測IB 網(wǎng)卡對多進程的通信支持相較于共享內(nèi)存并不友好，多進程會平分網(wǎng)卡帶寬，導致整體性能下降。而在進行大規(guī)模節(jié)點運算時，網(wǎng)卡是節(jié)點間通信的主力設備，應該盡可能地保證網(wǎng)卡用于跨節(jié)點傳輸。因此，需要對UCX 的傳輸邏輯進行修改，使其在進行節(jié)點間通信時不使用網(wǎng)卡。

以MPI 為例，在其進行通信時，UCX 會調(diào)用遠程內(nèi)存訪問（RMA）［24］和活動消息（AM）等操作來實現(xiàn)快速的節(jié)點間通信。在涉及進程間通信時，UCX同樣也會選擇網(wǎng)卡來調(diào)用這些操作進行傳輸。

在“嵩山”超級計算平臺中，MPI 節(jié)點內(nèi)通信使用的設備有memory 和mlx5。memory 會調(diào)用am、am_bw 和 rma_bw 操 作；mlx5 網(wǎng)卡會調(diào)用am_bw 和rma_bw 操作。因此，mlx5 網(wǎng)卡在節(jié)點內(nèi)通信時所調(diào)用的操作完全可以被memory 所取代。程序調(diào)用am_bw 和rma_bw 操作之 前，UCT 會執(zhí)行ucp_wireup_add_bw_lanes 函數(shù)，選出合適的傳輸，以此建立支持相應功能的endpoint。對此函數(shù)進行分析可以發(fā)現(xiàn)，函數(shù)調(diào)用ucp_wireup_select_transport，根據(jù)bitmap 選出支持am_bw 或rma_bw 的傳輸，隨后函數(shù)將傳輸放入ep 的配置文件中，等待endpoint 的創(chuàng)建，這些操作都發(fā)生在連接的準備階段。

在實驗確定的最佳色譜條件下，選取1#果酒樣品，分別加入10，50，100 mg/L標準混合溶液，平行進行6次實驗，實驗結(jié)果見表3。回收率為81.6%～102.8%，相對平均偏差不大于4.4%，說明方法精密度高，準確度好。

本文在ucp_wireup_add_bw_lanes 函數(shù)中添加判斷。在函數(shù)循環(huán)搜尋可用傳輸并將其添加到設備的dev_bitmap 后，讀取出Worker 的上下文信息，判斷此時的設備是否為共享內(nèi)存?zhèn)鬏敚喝绻枪蚕韮?nèi)存?zhèn)鬏敚瑒tbreak 跳出循環(huán)，不再搜索額外的傳輸；如果不是共享內(nèi)存?zhèn)鬏?，則正常循環(huán)，搜尋可用傳輸。修改后的程序流程如圖4 所示，可以這樣做的原因是搜索過程中的設備次序memory 排在mlx5 網(wǎng)卡之前，當選擇出共享內(nèi)存?zhèn)鬏敃r，函數(shù)退出，便不會檢索到mlx5 網(wǎng)卡，從而在進行節(jié)點內(nèi)的進程間通信時只使用共享內(nèi)存通信而不是網(wǎng)卡傳輸。

圖4 優(yōu)化后的程序流程Fig.4 Optimized program procedure

使用osu_benchmark 以4 MB 包長測得單節(jié)點內(nèi)2～32 進程的alltoall 集合通信延遲數(shù)據(jù)，如圖5 所示，其中，before 是優(yōu)化前同時使用網(wǎng)卡rc 傳輸和共享內(nèi)存?zhèn)鬏數(shù)耐ㄐ艛?shù)據(jù)，after 是僅使用共享內(nèi)存?zhèn)鬏數(shù)耐ㄐ艛?shù)據(jù)。從圖5 可以看出，在節(jié)點內(nèi)通信時，隨著PPN（Processes Per Node）的增加，2 種傳輸方式的延遲差距愈加明顯，優(yōu)化后的通信延遲相較于優(yōu)化前最多降低了70%。

圖5 節(jié)點內(nèi)alltoall 測試結(jié)果Fig.5 Intra-node alltoall test results

測試不同PPN 下的點對點通信帶寬數(shù)據(jù)，如圖6所示。從中可以明顯看出，在PPN 大于8 時，僅使用共享內(nèi)存?zhèn)鬏數(shù)耐ㄐ判阅軆?yōu)于使用IB 網(wǎng)卡的通信性能，此外，如果節(jié)點內(nèi)的進程間通信使用了網(wǎng)卡傳輸，在絕大多數(shù)情況下，網(wǎng)卡通信還會對本來的進程間通信造成負面影響，降低整體的通信帶寬性能。

圖6 節(jié)點內(nèi)點對點帶寬測試結(jié)果Fig.6 Intra-node p2p bandwidth test results

2.3 共享內(nèi)存通信選擇優(yōu)化

“嵩山”平臺的MPI 庫中存在不同的節(jié)點內(nèi)通信機制，圖7 主要展示了其中的2 種。傳統(tǒng)的雙副本拷貝的共享內(nèi)存實現(xiàn)，其傳輸數(shù)據(jù)涉及一個共享的緩沖區(qū)空間，由本地進程來交換消息，如圖7（a）所示。但是，這種方式僅適用于小消息，對于較大的消息，雙副本拷貝會給CPU 帶來額外的負擔，導致緩存污染和帶寬的浪費。圖7（b）展示了支持內(nèi)核輔助的共享內(nèi)存?zhèn)鬏攲崿F(xiàn)［25］，傳輸實現(xiàn)依靠內(nèi)核的援助，內(nèi)核模塊可以為節(jié)點內(nèi)通信提供單拷貝機制，在傳輸較大消息時會大幅提升傳輸效率。

圖7 2 種共享內(nèi)存通信機制Fig.7 Two shared memory communication mechanisms

對于第2 種通信方式，“嵩山”平臺的MPI 庫支持CMA 和KNEM［26］這2 種內(nèi)核模塊。CMA 引入了2 個系統(tǒng)調(diào)用，分別是process_vm_readv 和process_vm_writev，它們根據(jù)進程的PID 和遠程虛擬地址直接讀寫另一個進程的內(nèi)存［27］。對于使用KNEM 內(nèi)核的通信，發(fā)送進程在KNEM 驅(qū)動中聲明一個發(fā)送緩沖區(qū)（不管是否連續(xù)），并將相應的標識符cookie傳遞給接收進程，接收進程接收到cookie 并請求KNEM 驅(qū)動從cookie 緩沖區(qū)復制到它的本地緩沖區(qū)（連續(xù)或非連續(xù)）［26］。

本文使用osu_benchmark 分別指定CMA 和KNEM 傳輸，測得2 種共享內(nèi)存通信的帶寬與延遲如表1 所示。在“嵩山”超算平臺下對輸出的UCX 日志進行分析發(fā)現(xiàn)，節(jié)點在進行共享內(nèi)存?zhèn)鬏敃r，無論何種情況都只會選擇CMA 進行通信，并不會選擇帶寬更高、延遲更低的KNEM。

表1 CMA 與KNEM 的性能參數(shù)Table 1 Performance parameters of the CMA and KNEM

進程間在進行共享內(nèi)存通信時，通過rma_bw 操作來進行高速的遠程內(nèi)存訪問。在建立連接前，UCT 會根據(jù)UCX 提供的一套公式來計算傳輸評分，選出rma_bw 中評分最高的傳輸，添加到連接通道（lanes）中。

本文對rma_bw 操作傳輸選擇的評分機制進行分析。在UCT 中，計算評分時以256 KB 的消息大小為基準，調(diào)用rma_bw 操作的傳輸?shù)脑u分為時間開銷的倒數(shù)，如式（1）所示：

設mcost為內(nèi)存域注冊開銷，注冊開銷近似為一個線性函數(shù)，如式（2）所示：

其中：omd為固定開銷；ggrowth為增長系數(shù)；ssize為數(shù)據(jù)大小（256 KB）。設bl和br分別為本地和遠程的帶寬大小，因此，總開銷為256 KB 消息的傳輸時延、內(nèi)存注冊開銷mcost與傳輸接口間延遲llr的累加，如下：

對于節(jié)點中的每個進程，其帶寬b在UCX 中的計算方式如式（4）所示：

其中：bdedicated為專用帶寬；bshared為共享帶寬。

對平臺的UCX 源代碼進行分析，可以發(fā)現(xiàn)：在UCX 1.9.0 的帶寬設置下，CMA 擁有11 145.00 MB的dedicated 帶 寬，而KNEM 是13 862 MB 的shared帶寬。根據(jù)srma的計算公式，在PPN 不為1 時，UCX在計算KNEM 和CMA 的rma_bw 評分時帶寬會存在巨大差異，從而導致永遠不會選擇KNEM 傳輸。這是因為早期KNEM 對多進程支持不如CMA，單進程時KNEM 會有更高的帶寬，但是存在多進程通信時，KNEM 性能將不如CMA，因而將KNEM 帶寬值設置為shared。但是，“嵩山”超級計算平臺所具有的優(yōu)化KNEM 對多進程的支持極好，同時支持高性能單拷貝消息傳輸。因此，本文將KNEM 的帶寬從shared 改為dedicated，使KNEM 獲得了更合理的評分，從而在進行集合通信時共享內(nèi)存方面的傳輸會更多地選擇帶寬更高、延遲更低的KNEM。

在大部分通信中，KNEM 和CMA 兩者差異較小，但是在涉及節(jié)點內(nèi)進程間gather 通信時，KNEM內(nèi)核相對CMA 內(nèi)核有較為明顯的性能提升，并且隨著PPN 的增加提升效果愈加明顯，如圖8 所示。

圖8 節(jié)點內(nèi)gather 測試結(jié)果Fig.8 Intra-node gather test results

3 數(shù)據(jù)測試與驗證

3.1 實驗環(huán)境

在“嵩山”超級計算機的固化節(jié)點上進行實驗，單個節(jié)點配置為32 核2.0 GHz CPU，網(wǎng)卡采用Mellanox ConnectX-6，以HDR 模式（200 Gb/s）工作。操作系統(tǒng)為CentOS 7.6，內(nèi)核版本為3.10.0-957.el7.x86_64。

在本次測試中，使用的MPI 版本為Open MPI v4.0.4rc3，它在平臺的共享內(nèi)存通信時支持KNEM和CMA 內(nèi)核。使用的HPCX 版本為2.7.4，UCX 版本為UCX 1.9。對于點到點和集合通信測試，使用osu_benchmark v5.5 來測試并記錄通信性能數(shù)據(jù)。在性能測試對比數(shù)據(jù)中，before 的通信底層是目前在用的由ITIGIN 優(yōu)化后的UCX 正式版本，after 采用本文優(yōu)化后的UCX 庫。

3.2 節(jié)點內(nèi)集合通信測試

首先測試優(yōu)化后的UCX 庫在單節(jié)點內(nèi)的通信表現(xiàn)。圖9～圖11 展示了單節(jié)點內(nèi)不同PPN 下的4 MB 包長的MPI 集合通信測試數(shù)據(jù)，橫坐標為使用核心數(shù)（總進程數(shù)），縱坐標為平均通信延遲，每個核心綁定一個進程進行通信。從中可以看出，使用優(yōu)化后UCX 的MPI 集合通信能力有了明顯提升，alltoall 的通信性能提升尤為明顯，延遲最多降至優(yōu)化前的30%（圖9），gather 的通信延遲最多約降至優(yōu)化前的55%（圖10），allreduce 的通信延遲最多約降至優(yōu)化前的69%（圖11）。

圖9 優(yōu)化前后節(jié)點內(nèi)alltoall 測試結(jié)果Fig.9 Intra-node alltoall test results before and after optimization

圖10 優(yōu)化前后節(jié)點內(nèi)gather 測試結(jié)果Fig.10 Intra-node gather test results before and after optimization

圖11 優(yōu)化前后節(jié)點內(nèi)allreduce 測試結(jié)果Fig.11 Intra-node allreduce test results before and after optimization

3.3 節(jié)點間集合通信測試

對于節(jié)點間的集合通信，本文對2 個規(guī)模（32 節(jié)點和100 節(jié)點）進行測試。對于32 節(jié)點的規(guī)模，選取分屬lka 2 個交換機的32 個節(jié)點，每個交換機16 個節(jié)點，測試消息包長為1 MB。經(jīng)過測試發(fā)現(xiàn)，在節(jié)點間集合通信時，其他集合通信測試效果與優(yōu)化前一致，allgather通信產(chǎn)生了較為明顯的差異，如圖12 所示。

圖12 32 節(jié)點allgather 測試結(jié)果Fig.12 32 nodes allgather test results

本文在8 箱的節(jié)點中隨機選擇100 個節(jié)點，進行100 個節(jié)點間的集合通信測試，獲得節(jié)點間的2～18 PPN 下1 MB 包長的集合通信延遲數(shù)據(jù)。從圖13 可以看出，優(yōu)化后的UCX 在allgather 集合通信中取得了極為明顯的優(yōu)化效果，延遲最多可降至原來的20%，并且隨著進程的增多差距逐漸變大。其他的集合通信測試優(yōu)化前后數(shù)據(jù)基本保持一致。

圖13 100 節(jié)點allgather 測試結(jié)果Fig.13 100 nodes allgather test results

4 結(jié)束語

“嵩山”超級計算平臺支持多種并行編程模型，對高速互聯(lián)網(wǎng)絡進行優(yōu)化有助于提升平臺的整體通信性能，為平臺的并行編程模型提供良好的底層通信支持。本文對“嵩山”超級計算平臺上的節(jié)點進行測試，獲得了節(jié)點間與節(jié)點內(nèi)的通信性能數(shù)據(jù)，并且發(fā)現(xiàn)IB 網(wǎng)卡在節(jié)點內(nèi)多PPN 通信中存在的局限性。然后，對平臺的主要通信框架UCX 進行分析與優(yōu)化，解決了節(jié)點內(nèi)進程間通信占用網(wǎng)卡的問題，同時改善了UCX 對共享內(nèi)存?zhèn)鬏數(shù)倪x擇機制。優(yōu)化后的UCX 對大PPN 下的節(jié)點間allgather 集合通信以及節(jié)點內(nèi)的進程間集合通信性能提升效果明顯。

由于RDMA 具有復雜性，很多因素都可能影響RDMA 系統(tǒng)的整體通信性能。下一步將找出其他制約節(jié)點間通信速度的因素，對算法進行改進，使得節(jié)點間的其他集合通信能力得到加強。此外，UCX 根據(jù)PPN 來預測帶寬，依此帶寬來選擇傳輸，這種帶寬計算方法還不夠準確，未來將對此進行改進，從而改善UCX 的傳輸選擇評分機制。