這是 標準并行編程 系列的第三篇文章，講述在標準語言中使用并行性來加速計算的優點。

用標準語言并行性開發加速代碼

多個 GPU 標準 C ++并行編程，第 1 部分

在第 1 部分中，我們解釋了：

C ++并行編程的基礎

格子玻爾茲曼方法（ LBM ）

采取了第一步來重構 PalabOS 庫，以使用標準 C ++高效地運行 GPU 。

在這篇文章中，我們繼續優化 ISOC ++算法的性能，然后使用 MPI 來跨多個 GPU 來縮放應用。

爭取最佳性能

期望 CPU 到 GPU 端口的性能低于專用 HPC 代碼的性能似乎很自然。畢竟，您受到軟件體系結構、已建立的 API 的限制，以及考慮用戶群期望的復雜額外功能的需要。不僅如此， C ++標準并行化的簡單編程模型允許比專用語言（如 CUDA ）更少的手動微調。

在現實中，通常可以將這種性能損失控制和限制到可以忽略不計的程度。關鍵是分析各個代碼部分的性能指標，消除不能反映軟件框架實際需求的性能瓶頸。

一個好的做法是為數值算法的核心組件維護一個單獨的原理證明代碼。這種方法的性能可以更自由地優化，并與完整、復雜的軟件框架（如 Palabos 中的 STLBM library ）進行比較。此外，像nvprof這樣支持 GPU 的探查器可以有效地突出性能瓶頸的根源。

以下建議重點介紹了典型的性能問題及其解決方案：

不要觸摸 CPU 上的數據

了解你的算法

建立績效模型

不要觸摸 CPU 上的數據

性能損失的一個常見原因是 CPU 和 GPU 內存之間的隱藏數據傳輸，這可能非常慢。在 CUDA 統一內存模型中，每當您從 CPU 訪問 GPU 數據時，就會發生這種類型的傳輸。觸摸單個字節的數據可能會導致災難性的性能損失，因為整個內存頁都是一次性傳輸的。

顯而易見的解決方案是盡可能只在 GPU 上操作數據。這需要仔細搜索代碼中所有對數據的訪問，然后將它們包裝成并行算法調用。雖然這有點健壯，但即使是最簡單的操作也需要這個過程。

顯而易見的地方是數據統計的后處理操作或中間評估。另一個經典的性能瓶頸出現在 MPI 通信層，因為您必須記住在 GPU 上執行數據打包和解包操作。

在 GPU 上表達算法說起來容易做起來難，因為for_each和transform_reduce的形式主義主要適用于結構均勻的內存訪問。

在不規則數據結構的情況下，使用這兩種算法避免競爭條件并保證合并的內存訪問是痛苦的。在這種情況下，您應該繼續執行下一個建議，熟悉 C ++中提供的并行算法的家族。

了解你的算法

到目前為止，并行 STL 似乎只不過是一種用奇特的函數語法表達parallel for loops的方式。實際上， STL 提供了for_each和transform_reduce之外的大量算法，這些算法對表達數值方法非常有用，包括排序和搜索算法。

exclusive_scan算法計算累積和，值得特別提及，因為它被證明通常對非結構化數據的重新索引操作非常有用。例如，考慮 MPI 通信的打包算法，其中預先由每個網格節點貢獻給通信緩沖器的變量的數目是未知的。在這種情況下，需要線程之間的全局通信來確定每個網格節點寫入緩沖區的索引。

下面的代碼示例顯示了如何使用并行算法在 GPU 上以良好的并行效率解決此類問題：

// Step 1： compute the number of variables contributed by every node.

int* numValuesPtr = allocateMemory（numberOfCells）;

for_each（execution：：par_unseq， numValuesPtr， numValuesPtrl + numberOfCells， ［=］（int& numValues）

{ int i = &numValues - numValuesPtr; // Compute number of variables contributed by current node. numValues = computeNumValues（i）;

} ）;

// 2. Compute the buffer index for every node.

int* indexPtr = allocateMemory（numberOfCells）;

exclusive_scan（execution：：par_unseq， numValuesPtr， numValuesPtr + numberOfCells， indexPtr， 0）;

// 3. Pack the data into the buffer.

for_each（execution：：par_unseq， indexPtr， indexPtr + numberOfCells， ［=］（int& index）

{ int i = &index - indexPtr; packCellData（i， index）;

} ）;

這個例子讓你享受到基于算法的 GPU 編程方法的表達能力：代碼不需要同步指令或任何其他低級構造。

建立績效模型

性能模型通過瓶頸分析為算法的性能建立上限。這通常將峰值處理器性能（以觸發器為單位）和峰值內存帶寬視為限制硬件特性的主要因素。

正如在上一篇文章的示例：Lattice Boltzmann 軟件 Palabos 部分中所討論的，LBM 代碼的計算與內存訪問的比率較低，并且在現代 GPU 上完全受內存限制。也就是說，至少如果您使用單精度算術或為雙精度算術優化的 GPU。

峰值性能簡單地表示為 GPU 的內存帶寬與代碼中執行的內存訪問次數之間的比率。直接的結果是，將 LBM 代碼從雙精度算術轉換為單精度算術將使性能加倍。

圖 1 顯示了在 NVIDIA A100 （ 40 GB ） GPU 上獲得的 Palabos GPU 端口在單精度和雙精度浮點上的性能。

圖 1 。 3D 蓋驅動腔體的 Palabos 性能（ 6003網格節點）在 A100 （ 40 GB ） GPU 上以單精度和雙精度運行。型號： TRT ， D3Q19

執行的測試用例是湍流狀態下蓋驅動腔中的流動，具有簡單的立方幾何結構。然而，這種情況包括邊界條件，并表現出復雜的流動模式。性能以每秒百萬次晶格節點更新（ MLUPS ，越多越好）來衡量，并與假設 GPU 內存在峰值容量下被利用的理論峰值進行比較。

該代碼在雙精度下達到 73% 的峰值性能，在單精度下達到 74% 。這種性能指標在 LB 模型的最新實現中很常見，與所使用的語言或庫無關。

盡管一些實現可能會增加幾個百分點，并達到接近 80% 的值，但很明顯，我們正在接近性能模型隱含的硬限制。從大的角度來看，代碼的單 – GPU 性能是最好的。

重用現有的 MPI 后端以獲得多 GPU 代碼

當 C ++并行算法無縫地集成到現有的軟件項目中以加速關鍵代碼部分時，沒有什么能阻止您重用項目的通信后端以達到多 GPU 性能。但是，您需要密切關注通信緩沖區，確保它不會繞過 CPU 內存，這將導致代價高昂的頁面錯誤。

我們首次嘗試在多個 GPU 上運行帶有 GPU 端口的 Palabos 版本，雖然產生了技術上正確的結果，但沒有表現出可接受的性能。不是加速，而是從 1 切換到 2 GPU 將速度降低了一個數量級。這個問題可以追溯到通信數據的打包和解包。在最初的后端，這是在 CPU 上執行的，并且是在 CPU 內存中的其他不必要數據訪問實例上執行的，例如調整通信緩沖區的大小。

這些問題可以在探查器的幫助下發現。分析器會突出顯示統一內存中出現的所有頁面錯誤，并通過將相應的代碼部分移動到并行算法來修復。“了解你的算法”部分解釋了如果數據遵循不規則模式，如何打包和解包通信緩沖區。

在這一點上，使用標準的 C ++，除了 MPI 以外沒有任何擴展，您可以獲得一個混合 CPU / GPU 軟件項目，具有最先進的性能，在單 G GPU 和多 GPU 上的并行性能。

不幸的是，由于語言規范和相應的 GPU 實現的當前限制，多 GPU 性能仍然低于預期。在未來的 C ++技術標準并行化技術的改進中，我們將基于 C ++標準之外的技術提供一些解決方案。

協調多 CPU 和多 GPU 代碼的執行

雖然這篇文章主要關注混合 CPU 和 GPU 編程，但我們無法避免在 CPU 部分討論混合并行性（ MPI 或多線程）問題。

例如， Palabos 的原始版本是非混合的，它使用 MPI 通信層在 CPU 的核心之間以及整個網絡中分配工作。移植到 GPU 后，生成的多 CPU 和多 GPU 代碼會自動將單個 CPU 內核與每個 MPI 任務中的完整 GPU 進行分組，使 CPU 的動力相對不足。

每當需要或方便將計算密集型任務保留在 CPU 上時，這會導致性能瓶頸。在流體動力學中，在預處理階段（如幾何體處理或網格生成）通常會出現這種情況。

顯而易見的解決方案是使用多線程從 MPI 任務中訪問多個 CPU 內核。這些線程的共享內存空間可以通過 CUDA 統一內存形式直接與 GPU 共享。

然而， C ++并行算法不能被重用以服務于 GPU 和多核 CPU 執行的兩個目的。這是因為 C ++不允許從語言內選擇并行算法的目標平臺。

雖然 C ++線程確實提供了一種解決這個問題的方法，但我們發現 OpenMP 提供了最方便和最不受干擾的解決方案。在這種情況下，for loop的 OpenMP 注釋足以將分配給當前 MPI 任務的網格部分分布到多個線程上。

通過固定內存進行通信

在當前版本的 HPC SDK 中， CUDA 統一內存模型與 MPI 相結合，表現出另一個性能問題。

由于 MPI 通信層希望數據具有固定的硬件地址（所謂的pinned memory），因此托管內存區域中的任何緩沖區都會首先隱式復制到主機 CPU 上的固定內存緩沖區中。由于 GPU 和 CPU 之間的傳輸，此操作最終可能會非常昂貴。

因此，通信緩沖區應明確固定到 GPU 內存地址。對于nvc++ compiler，這是通過使用cudaMalloc分配通信緩沖區來實現的：

// Allocate the communication buffer

// vector《double》 buffer（N）;

// double* buffer = buffer.data（）;

double* buffer; cudaMalloc（（void**）&buffer， N * sizeof（double））;

for_each（buffer， buffer + N， … // Proceed with data packing

另一種解決方案是用推力庫中的thrust：：device_vector替換 STL 向量，默認情況下，推力庫使用固定 GPU 內存。

在不久的將來， HPC SDK 將為用戶更高效、更自動地處理這些情況。這樣他們就不必伸手去拿cudaMalloc或thrust：：device_vector。所以，請繼續關注！

在本文列出的各種改進之后， Palabos 庫在一個帶有四個 GPU 的 DGX A100 （ 40-GB ）工作站上進行了測試，再次用于蓋驅動型腔的基準情況。獲得的性能如圖 2 所示，并與 48 核 Xeon Gold 6240R CPU 上獲得的性能進行了比較：

圖 2 。 3D 蓋驅動腔體的 Palabos 性能（ 6003網格節點）在 48 核 Xeon Gold 6240R CPU 和 DGX A100 （ 40 GB ）工作站上，一次使用一個 GPU ，一次使用四個 GPU 。型號： TRT ， D3Q19 ，單精度

對于 Xeon Gold ， Palabos 的原始實現被證明更高效，并用于 48 個 MPI 任務，而單 GPU 和四 GPU 執行使用并行算法后端，并使用nvc++編譯。

性能數據顯示，與單次執行 GPU 相比， 4- GPU 執行的速度提高了 3.27 倍。這相當于一個非常令人滿意的并行效率 82% ，在一個強大的擴展機制，在兩個執行相同的總域大小。在弱擴展情況下，使用 4 倍于 4- GPU 執行的問題大小，加速比增加到 3.72 （效率 93% ）。

圖 2 還顯示，當使用未固定的通信緩沖區時，例如當 MPI 通信緩沖區未分配cudaMalloc時，并行效率從 82% 下降到 61% 。

最終，四 GPU DGX 工作站的運行速度比 Xeon Gold CPU 快 55 倍。雖然由于兩臺機器的范圍不同，直接比較可能不公平，但它提供了通過將代碼移植到 GPU 獲得的加速度感。 DGX 是一個連接到公共電源插頭的臺式工作站，但它提供的性能在 CPU 群集上只能通過數千個 CPU 內核獲得。

結論

您已經看到 C ++標準語言并行性可以用來把像 PalabOS 這樣的庫移植到 GPU ，代碼性能驚人地提高。

對于 Palabos 庫的最終用戶來說，這種性能提升是通過一行更改來實現的，即從 CPU 后端切換到 GPU 后端。

對于 Palabos 庫開發人員來說，開發相應的 GPU 后端需要做一些工作。

然而，這項工作不需要學習新的領域特定語言，也不依賴于 GPU 體系結構的詳細知識。

關于作者

Jonas Latt 是瑞士日內瓦大學計算機科學系的副教授。他從事高性能計算和計算流體力學的研究，并在包括地球物理、生物醫學和航空航天領域在內的跨學科領域進行應用。他是 lattice Boltzmann 復雜流動模擬開源軟件 Palabos 的最初開發者和當前共同維護者。他以前在日內瓦大學獲得物理學和計算機科學博士學位，并通過塔夫斯大學（波士頓，美國）和綜合理工學校 F.E.EdRaelde 洛桑 EPFL （瑞士）的研究，并作為 CFD 公司 FuluKIT 的聯合創始人，對流體力學感興趣。

Christophe Guy Coreixas 是一名航空工程師， 2014 年畢業于 ISAE-SUPAERO （法國圖盧茲）。 2018 年，他在 CERFACS 從事面向行業應用的可壓縮晶格玻爾茲曼方法研究時獲得了博士學位（流體動力學）。作為日內瓦大學計算機科學系的博士后，克里斯多夫現在開發格子玻爾茲曼模型來模擬航空、多物理和生物醫學流程。

Gonzalo Brito 是 NVIDIA 計算性能與 HPC 團隊的高級開發技術工程師，工作于硬件和軟件的交叉點。他熱衷于讓加速計算變得更容易實現。在加入NVIDIA 之前，岡薩洛在 RWTH 亞琛大學空氣動力學研究所開發了多物理方法，用于顆粒流。

Jeff Larkin 是 NVIDIA HPC 軟件團隊的首席 HPC 應用程序架構師。他熱衷于高性能計算并行編程模型的發展和采用。他曾是 NVIDIA 開發人員技術小組的成員，專門從事高性能計算應用程序的性能分析和優化。 Jeff 還是 OpenACC 技術委員會主席，曾在 OpenACC 和 OpenMP 標準機構工作。在加入NVIDIA 之前，杰夫在位于橡樹嶺國家實驗室的克雷超級計算卓越中心工作。

審核編輯：郭婷