這是 標(biāo)準(zhǔn)并行編程 系列的第二篇文章，講述在標(biāo)準(zhǔn)語言中使用并行性來加速計(jì)算的優(yōu)點(diǎn)。

用標(biāo)準(zhǔn)語言并行性開發(fā)加速代碼

多個(gè) GPU 標(biāo)準(zhǔn) C ++并行編程，第 2 部分

將應(yīng)用程序移植到 GPU 的難度因情況而異。在最佳情況下，您可以通過調(diào)用現(xiàn)有的 GPU 優(yōu)化庫來加速關(guān)鍵代碼部分。例如，當(dāng)模擬軟件的構(gòu)建塊由 BLAS 線性代數(shù)函數(shù)組成時(shí)，可以使用 cuBLAS 對其進(jìn)行加速。

但在許多代碼中，你不能四處做一些手工工作。在這些場景中，您可以考慮使用特定于域的語言，例如 CUDA 來針對特定的加速器?；蛘撸梢允褂没谥噶畹姆椒?，如 OpenMP 或 OpenACC ，以保持原始語言，并使用相同的代碼針對主機(jī)和各種類型的設(shè)備。

標(biāo)準(zhǔn)并行性

隨著本機(jī)形式的并行在C++、FORTRAN和 Python 編程語言的現(xiàn)代版本中的出現(xiàn)，現(xiàn)在可以利用類似的高級方法而不需要語言擴(kuò)展。

C ++中的標(biāo)準(zhǔn)并行性

我們的重點(diǎn)是 C ++語言，它作為 C ++ 17 標(biāo)準(zhǔn)，在標(biāo)準(zhǔn)庫中提供了許多算法的并行版本。底層編程模型是前面提到的兩種方法的混合體。它的工作方式類似于基于庫的方法，因?yàn)?C ++提供了用于排序、搜索和累積和的常見任務(wù)的并行算法，并且可以在即將到來的版本中添加對特定領(lǐng)域特定算法的支持。此外，以通用for_each和transform_reduce算法的形式提供了并行手寫循環(huán)的形式。

C ++并行算法通過語言的本地語法來代替非標(biāo)準(zhǔn)擴(kuò)展來表示并行性。通過這種方式，它們保證了所開發(fā)軟件的長期兼容性和可移植性。這篇文章還表明，獲得的性能通常與 CUDA C ++等傳統(tǒng)方法獲得的性能相當(dāng)。

這種方法的新穎之處在于它無縫地集成到現(xiàn)有的代碼庫中。此方法允許您保留軟件體系結(jié)構(gòu)，并有選擇地加快關(guān)鍵組件的性能。

將 C ++項(xiàng)目移植到 GPU 可以簡單到通過調(diào)用for_each或transform_reduce來替換所有的循環(huán)，如果它包含了一個(gè)還原。

我們將通過典型的重構(gòu)步驟來克服當(dāng)前 C ++編譯器不兼容問題。這篇文章列出了出于性能原因所需的修改，這些修改更具普遍性，原則上獨(dú)立于編程形式。這包括以允許合并內(nèi)存訪問的方式重新構(gòu)造數(shù)據(jù)的要求。

對于當(dāng)前編譯器， C ++并行算法只針對單個(gè) GPU ，而需要明確的 MPI 并行性來針對多個(gè) GPU 。為此，重用現(xiàn)有并行 CPU 代碼的 MPI 后端非常簡單，我們將介紹一些實(shí)現(xiàn)最先進(jìn)性能的指導(dǎo)原則。

我們將討論這些實(shí)施規(guī)則、指南和最佳實(shí)踐，并以 Palabos 為例進(jìn)行說明， Palabos 是一個(gè)基于晶格玻爾茲曼方法（ LBM ）的計(jì)算流體力學(xué)軟件庫。 PalabOS 在 2021 中被移植到多個(gè) GPU 硬件中，只有幾個(gè)月的工作，并且說明了對于原來的代碼很難適應(yīng) GPU 的建議重構(gòu)步驟的需要。由于廣泛使用面向?qū)ο蟮臄?shù)據(jù)結(jié)構(gòu)和編碼機(jī)制，原始代碼對 GPU 的適應(yīng)性較差。

您知道使用 C ++標(biāo)準(zhǔn)并行性允許混合算法，其中一些算法在 GPU 上執(zhí)行，但有些算法保持在 CPU 上。這完全取決于它們是否適合 GPU 執(zhí)行，或者僅僅取決于它們的 GPU 端口的進(jìn)度狀態(tài)。這一特性突出顯示了 C ++標(biāo)準(zhǔn)并行性的主要優(yōu)點(diǎn)之一，與保持原有體系結(jié)構(gòu)和大部分軟件代碼的完整性保持一致。

使用 C ++標(biāo)準(zhǔn)并行編程的 GPU 程序設(shè)計(jì)

如果這是您第一次聽到 C ++并行算法，您可能想讀 用標(biāo)準(zhǔn)語言并行性開發(fā)加速代碼 ，它介紹了 C ++中的標(biāo)準(zhǔn)語言并行性的主題， FORTRAN 和 Python 。

基本概念非常簡單。您可以通過執(zhí)行策略來獲得許多標(biāo)準(zhǔn)的 C ++算法在主機(jī)上或設(shè)備上并行運(yùn)行，作為一個(gè)額外的參數(shù)提供給算法。在本文中，我們使用par_unseq execution policy，它表示對不同元素的計(jì)算是完全獨(dú)立的。

以下代碼示例執(zhí)行并行操作，將std：：vector《double》的所有元素乘以 2 ：

for_each（execution：：par_unseq， begin（v）， end（v）， ［］（double& x） { x *= 2.0;

}）;

該算法由nvc++ compiler和-stdpar option編譯，在 GPU 上執(zhí)行。根據(jù)編譯器、編譯器選項(xiàng)和并行算法的實(shí)現(xiàn)，還可以在多核 CPU 或其他類型的加速器上獲得多線程執(zhí)行。

此示例使用通用的for_each算法，該算法以函數(shù)對象的形式將任何元素操作應(yīng)用于向量 v 。在本例中，它是一個(gè)內(nèi)聯(lián) lambda 表達(dá)式?？梢允褂盟惴╰ransform_reduce而不是for_each來指定額外的縮減操作。

在for_each算法調(diào)用中，調(diào)用 lambda 函數(shù)時(shí)會(huì)引用連續(xù)的容器元素。但有時(shí)，為了訪問外部數(shù)據(jù)數(shù)組或?qū)崿F(xiàn)非本地模板，還必須知道元素的索引。

這可以通過在 C ++ C ++ 17 中的推力庫（包括NVIDIA HPC SDK ）和std：：ranges：：views：：iota中提供的counting_iterator迭代來完成，或者在 C ++ 20 中更新。在 C ++ 17 中，最簡單的解決方案是從當(dāng)前元素的地址推導(dǎo)索引。

使用 C ++標(biāo)準(zhǔn)并行性的雅可比示例

為了說明這些概念，下面是一個(gè)代碼示例，它使用并行 STL 計(jì)算非局部模具操作和誤差估計(jì)的縮減操作。它執(zhí)行雅可比迭代，計(jì)算每個(gè)矩陣元素的四個(gè)最近鄰的平均值：

void jacobi_iteration(vector const& v, vector& tmp) { double const* vptr = v.data(); double *tmp_ptr = tmp.data(); double l2_error = transform_reduce(execution::par_unseq, begin(v), end(v), 0., plus, [=](double& x) { int i = &x - vptr; // Compute index of x from its address. auto [iX, iY] = split(i); double avg = 0.25 * ( vptr[fuse(iX-1, iY)] + vptr[fuse(iX+1, iY)] + vptr[fuse(iX, iY-1)] + vptr[fuse(iX, iY+1)] ); tmp_ptr[i] = avg; return (avg – x) * (avg – x); } );
)

這里，split表示將線性索引i分解為 x 坐標(biāo)和 y 坐標(biāo)，fuse則相反。如果域是一個(gè)統(tǒng)一的nx-by-ny矩陣， Y 索引在內(nèi)存中順序運(yùn)行，則定義如下：

fuse = ［ny］（int iX， int iY） { return iY + ny * iX; }

split = ［ny］（int i） { return make_tuple（i / ny， i % ny）; }

當(dāng)算法同時(shí)執(zhí)行時(shí)，使用臨時(shí)向量存儲(chǔ)計(jì)算出的平均值可以保證確定性結(jié)果。

此代碼的完整和通用版本可從 gitlab.com/unigehpfs/paralg GitLab 存儲(chǔ)庫獲得。該存儲(chǔ)庫還包括一個(gè)混合版本（ C ++標(biāo)準(zhǔn)并行和 MPI ），它是圍繞本文提供的建議構(gòu)建的，在多個(gè) GPU 上高效運(yùn)行。

您可能已經(jīng)注意到，沒有明確的語句將數(shù)據(jù)從主機(jī)傳輸?shù)皆O(shè)備，然后再傳輸回來。 C ++標(biāo)準(zhǔn)實(shí)際上不提供任何這樣的語句，并且任何并行算法在一個(gè)設(shè)備上的實(shí)現(xiàn)必須依賴于自動(dòng)存儲(chǔ)器傳輸。通過NVIDIA HPC SDK ，這是通過 CUDA 統(tǒng)一內(nèi)存，從 CPU 和 GPU 訪問的單個(gè)存儲(chǔ)器地址空間來實(shí)現(xiàn)的。如果代碼在 CPU 上訪問此地址空間中的數(shù)據(jù)，然后在 GPU 上訪問，則內(nèi)存頁會(huì)自動(dòng)遷移到訪問處理器。

對于使用 GPU 加速 CPU 應(yīng)用程序， CUDA 統(tǒng)一內(nèi)存特別有用，因?yàn)樗鼓軌驅(qū)Ｗ⒂谝栽隽糠绞街饌€(gè)函數(shù)移植應(yīng)用程序的算法，而無需擔(dān)心內(nèi)存管理。

另一方面，隱藏?cái)?shù)據(jù)傳輸?shù)男阅荛_銷很容易抵消 GPU 的性能優(yōu)勢。通常，在 GPU 上生成的數(shù)據(jù)應(yīng)盡可能保存在 GPU 內(nèi)存中，通過并行算法調(diào)用表示其所有操作。這包括數(shù)據(jù)后處理，如數(shù)據(jù)統(tǒng)計(jì)計(jì)算和可視化。如本文 Part 2 所示，它還包括 MPI 通信的數(shù)據(jù)打包和解包。

按照這篇文章的建議，將代碼移植到 GPU 變得非常簡單，只需通過調(diào)用并行算法來替換所有時(shí)間關(guān)鍵的循環(huán)和相關(guān)的數(shù)據(jù)訪問。不過，最好記住， GPU 通常比 CPU 擁有更多的內(nèi)核，并且應(yīng)該暴露在更高級別的并行性中。例如，在下一節(jié)介紹的流體動(dòng)力學(xué)問題中，流體域被均勻的、類似矩陣的網(wǎng)格部分覆蓋。

在原始的 CPU 代碼中，每個(gè) CPU 核心按順序處理一個(gè)或多個(gè)網(wǎng)格部分，如圖 1 頂部所示。至于 GPU ，網(wǎng)格部分元素上的環(huán)路應(yīng)該并行，以完全占據(jù) GPU 核心。

示例： Lattice Boltzmann 軟件和 Palabos

LBM 采用顯式時(shí)間步格式求解流體流動(dòng)方程，涵蓋了廣泛的應(yīng)用。這包括經(jīng)過復(fù)雜幾何形狀的流動(dòng)，如多孔介質(zhì)、多相流、可壓縮超音速流等。

LBM 通常比其他解算器在數(shù)值網(wǎng)格的每個(gè)節(jié)點(diǎn)上分配更多變量。當(dāng)經(jīng)典的不可壓縮 Navier-Stokes 解算器僅用三個(gè)變量表示速度分量，外加一個(gè)臨時(shí)壓力項(xiàng)時(shí)， LBM 方法通常需要 19 個(gè)變量，稱為populations。因此， LBM 的內(nèi)存占用空間要高出 5-6 倍。如果 Navier Stokes 解算器使用臨時(shí)變量，或者如果系統(tǒng)中添加了進(jìn)一步的物理量（如密度和溫度），實(shí)際里程可能會(huì)有所不同。

因此，豐富的內(nèi)存訪問和較低的運(yùn)算強(qiáng)度是 LBM 的特點(diǎn)。在集群級 GPU ，像 NVIDIA V100 和 NVIDIA A100 一樣，性能完全受限于內(nèi)存訪問，甚至對于計(jì)算密集和復(fù)雜的 LBM 方案也是如此。

以 NVIDIA A100 40 GB GPU為例，它具有1555 Gb/s的內(nèi)存帶寬。在每一個(gè)明確的時(shí)間步長，每個(gè)節(jié)點(diǎn)訪問19個(gè)變量或［EZX27 ］，每個(gè)都占用八個(gè)字節(jié)，每個(gè)都是雙精度的。它們被計(jì)數(shù)兩次：一次用于從 GPU 內(nèi)存到 GPU 內(nèi)核的數(shù)據(jù)傳輸，另一次用于在計(jì)算操作后寫回 GPU 內(nèi)存。

假設(shè)一個(gè)完美的內(nèi)存子系統(tǒng)和最大的數(shù)據(jù)重用， LBM 的峰值吞吐量性能為每秒處理 1555 /（ 19 * 8 * 2 ）= 51.1 億個(gè)網(wǎng)格節(jié)點(diǎn)。在 LBM 術(shù)語中，通常使用每秒千兆晶格節(jié)點(diǎn)更新（ GLUPS ），例如 5.11 GLUPS 。

然而，在現(xiàn)實(shí)生活中的應(yīng)用程序中，每個(gè)節(jié)點(diǎn)都會(huì)額外讀取一些信息來管理域異常情況。在 Palabos 中，這是節(jié)點(diǎn)標(biāo)記的 32 位整數(shù)和額外數(shù)據(jù)數(shù)組的 64 位索引，有效地將峰值性能降低到 4.92 GLUPS 。

該模型提供了一種簡單的方法來估計(jì) LBM 代碼可以達(dá)到的最佳峰值性能，因?yàn)榫彺嬷胁贿m合足夠大的網(wǎng)格。我們在整個(gè)帖子中使用這個(gè)模型來證明用 C ++并行算法獲得的性能是一樣好的。在幾個(gè)百分點(diǎn)的差距之外，無論是 CUDA 、 OpenMP ，還是任何其他 GPU 形式主義，都不能做得更好。

LBM 巧妙地區(qū)分了由局部collision step表示的計(jì)算和封裝在streaming step中的內(nèi)存?zhèn)鬏敳僮?。以下代碼示例顯示了具有矩陣式拓?fù)浣Y(jié)構(gòu)的結(jié)構(gòu)化網(wǎng)格的典型時(shí)間迭代：

for (int i = 0; i < N; ++i) { // Fetch local populations "f" from memory. double f_local[19]; for (int k = 0; k < 19; ++k) { f_local[k] = f[i][k]; } collide(f_local); // Execute collision step. // Write data back to neighboring nodes in memory (streaming). auto [iX, iY, iZ] = split(i); for (int k = 0; k < 19; ++k) { int nb = fuse(iX+c[k][0], iY+c[k][1], iZ+c[k][2]); ftmp[nb][k] = f_local[k]; }
}

與前一節(jié)中的 Jacobi 迭代一樣，該函數(shù)將計(jì)算出的數(shù)據(jù)寫入temporary array ftmp，以避免多線程執(zhí)行期間出現(xiàn)爭用情況，這使其成為演示本文概念的理想候選。有 替代就地算法 可以避免內(nèi)存復(fù)制。然而，它們更復(fù)雜，因此不太適合用于說明目的。

自然過程的模擬和建模 課程介紹了LBM。有關(guān)如何使用C++并行算法開發(fā) GPU 的LBM代碼的更多信息，請參見多核格子玻爾茲曼模擬的跨平臺(tái)編程模型。

在本文中，我們使用 開源 LBM 庫 Palabos 來展示如何將現(xiàn)有的 C ++庫用并行算法移植到多 GPU 。乍一看， Palabos 似乎不適合 GPU 端口，因?yàn)樗鼜?qiáng)烈依賴面向?qū)ο蟮臋C(jī)制。然而，在 Palabos 的案例中，我們將介紹幾種變通方法，這些方法只需對代碼體系結(jié)構(gòu)進(jìn)行表面的更改即可實(shí)現(xiàn)最先進(jìn)的性能。

從面向?qū)ο笤O(shè)計(jì)轉(zhuǎn)向面向數(shù)據(jù)設(shè)計(jì)

為了服務(wù)于大型社區(qū)，Palabos強(qiáng)調(diào)多態(tài)性和其他面向?qū)ο蠹夹g(shù)。包含數(shù)據(jù)（種群）和方法（局部碰撞模型）的對象代表每個(gè)網(wǎng)格節(jié)點(diǎn)。這為開發(fā)新模型提供了一個(gè)方便的API，并提供了一個(gè)靈活的機(jī)制來調(diào)整模型從一個(gè)單元到另一個(gè)單元的物理行為或數(shù)值方面。

然而，由于數(shù)據(jù)布局效率低下、執(zhí)行路徑復(fù)雜，以及對虛擬函數(shù)調(diào)用的依賴，這種面向?qū)ο蟮姆椒ú惶m合在 GPU 上執(zhí)行。以下幾節(jié)將教您如何通過采用開發(fā)模型，以 GPU 友好的方式重構(gòu)代碼，我們在總括術(shù)語下稱之為data-oriented programming。

擺脫基于類的多態(tài)性

圖 2 的左半部分展示了 Palabos 中網(wǎng)格節(jié)點(diǎn)上沖突模型的典型代碼執(zhí)行鏈。算法的不同組件被疊加起來，并通過虛擬函數(shù)調(diào)用，包括底層的數(shù)值 LBM 算法（ RR ）、附加物理（“ Smagorinsky ”）和附加數(shù)值方面（左邊界）。

這個(gè)面向?qū)ο笤O(shè)計(jì)的教科書案例變成了代碼 GPU 端口的責(zé)任。這個(gè)問題的出現(xiàn)是因?yàn)楫?dāng)前版本的 HPCSDK 不支持 C ++并行算法中的 GPU 的虛函數(shù)調(diào)用。一般來說，出于性能原因，在 GPU 上應(yīng)該避免這種類型的設(shè)計(jì)，因?yàn)樗拗屏藞?zhí)行路徑的可預(yù)測性。

簡單的解決方法是將執(zhí)行鏈?zhǔn)占絾蝹€(gè)函數(shù)中，這些函數(shù)按順序顯式調(diào)用各個(gè)組件，并用唯一的標(biāo)記標(biāo)識(shí)它們。

在 Palabos 中，這個(gè)獨(dú)特的標(biāo)記是在序列化機(jī)制的幫助下生成的，該機(jī)制最初是為了支持動(dòng)態(tài)自適應(yīng)仿真的檢查點(diǎn)和網(wǎng)絡(luò)通信而開發(fā)的。這表明，如果重構(gòu)軟件項(xiàng)目的體系結(jié)構(gòu)足夠靈活，那么 GPU 端口的大部分重構(gòu)工作都是自動(dòng)完成的。

現(xiàn)在，您可以為每個(gè)網(wǎng)格節(jié)點(diǎn)提供一個(gè)標(biāo)記，標(biāo)識(shí)完整沖突步驟的代碼，并用一個(gè)大的 switch 語句表示沖突步驟：

switch（tag） { case rr_les： fun_rr_les（f_local）; break; case rr_les_BCleft： fun_rr_les_BCleft（f_local）; break; …

}

隨著 switch 語句變大，由于生成的內(nèi)核在 GPU 內(nèi)存中占用的空間，它可能會(huì)遇到性能問題。

另一個(gè)問題是軟件項(xiàng)目的可維護(hù)性。目前，如果不修改這個(gè) switch 語句（它是庫核心的一部分），就不可能提供新的碰撞模型。這兩個(gè)問題的解決方案在于，在編譯時(shí)使用 C ++模板機(jī)制在最終用戶應(yīng)用程序中生成具有選定數(shù)量的實(shí)例的切換語句。 Palabos-GPU 資源頁詳細(xì)介紹了這種技術(shù)。

重新安排內(nèi)存以鼓勵(lì)合并的內(nèi)存訪問

面向?qū)ο蟮脑O(shè)計(jì)還會(huì)導(dǎo)致內(nèi)存布局無法在 GPU 的多核架構(gòu)上高效處理。當(dāng)每個(gè)節(jié)點(diǎn)對 LBM 方案的 19 個(gè)局部種群進(jìn)行分組時(shí)，數(shù)據(jù)以結(jié)構(gòu)陣列（ AoS ）的形式結(jié)束（圖 3 ）。為了簡單起見，每個(gè)節(jié)點(diǎn)只顯示四個(gè)總體。

AoS 數(shù)據(jù)布局導(dǎo)致性能不佳，因?yàn)樗柚沽肆魇教幚聿襟E中的合并內(nèi)存訪問，而流式處理步驟由于非本地模板，在內(nèi)存訪問方面是算法最關(guān)鍵的部分。

數(shù)據(jù)應(yīng)該以陣列結(jié)構(gòu)（ SoA ）的方式對齊，在流式處理步驟中進(jìn)行通信的給定類型的所有群體都在連續(xù)的內(nèi)存地址上對齊。在這種重新安排之后，即使是一個(gè)相對簡單的 LBM 算法也能獲得接近典型 GPU 內(nèi)存帶寬的 80% 。

面向數(shù)據(jù)的設(shè)計(jì)意味著您將中心重要性賦予數(shù)據(jù)的結(jié)構(gòu)和布局，并圍繞此結(jié)構(gòu)構(gòu)建數(shù)據(jù)處理算法。面向?qū)ο蟮姆椒ㄍǔ２捎梅聪蚵窂健?/p>

GPU 端口的第一步應(yīng)該是了解應(yīng)用程序的理想數(shù)據(jù)布局。就 LBM 而言， GPU 上 SoA 布局的優(yōu)越性是眾所周知的事實(shí)。內(nèi)存布局和內(nèi)存遍歷算法的細(xì)節(jié)在之前發(fā)布的案例研究 開源 STLBM 代碼 中進(jìn)行了測試。

結(jié)論

在這篇文章中，我們討論了使用 C ++標(biāo)準(zhǔn)并行編程編寫 GPU 應(yīng)用程序的基本技術(shù)。我們還提供了晶格玻爾茲曼方法和 Palabos 應(yīng)用程序的背景信息，我們在案例研究中使用了這些信息。最后，我們討論了兩種方法，可以重構(gòu)源代碼，使其更適合在 GPU 上運(yùn)行。

在下一篇文章中，我們繼續(xù)使用這個(gè)應(yīng)用程序，并討論如何在NVIDIA上運(yùn)行時(shí)在C++應(yīng)用程序中獲得高性能。我們還演示了如何通過MPI擴(kuò)展應(yīng)用程序以使用多個(gè) GPU 。

關(guān)于作者

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

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

Gonzalo Brito 是 NVIDIA 計(jì)算性能與 HPC 團(tuán)隊(duì)的高級開發(fā)技術(shù)工程師，工作于硬件和軟件的交叉點(diǎn)。他熱衷于讓加速計(jì)算變得更容易實(shí)現(xiàn)。在加入NVIDIA 之前，岡薩洛在 RWTH 亞琛大學(xué)空氣動(dòng)力學(xué)研究所開發(fā)了多物理方法，用于顆粒流。

Jeff Larkin 是 NVIDIA HPC 軟件團(tuán)隊(duì)的首席 HPC 應(yīng)用程序架構(gòu)師。他熱衷于高性能計(jì)算并行編程模型的發(fā)展和采用。他曾是 NVIDIA 開發(fā)人員技術(shù)小組的成員，專門從事高性能計(jì)算應(yīng)用程序的性能分析和優(yōu)化。 Jeff 還是 OpenACC 技術(shù)委員會(huì)主席，曾在 OpenACC 和 OpenMP 標(biāo)準(zhǔn)機(jī)構(gòu)工作。在加入NVIDIA 之前，杰夫在位于橡樹嶺國家實(shí)驗(yàn)室的克雷超級計(jì)算卓越中心工作。

審核編輯：郭婷