圖 1 ：由于負(fù)載較寬，內(nèi)核持續(xù)時間減少

第二步：寄存器使用

我們可能想到此為止并宣布成功，但使用 NVIDIA Nsight Compute 對程序執(zhí)行的深入分析表明，即使我們將加載指令的數(shù)量減少了一半，我們也沒有從根本上改變對內(nèi)存子系統(tǒng)的請求速率。原因是一條扭曲加載指令（即 32 個線程同時發(fā)出加載指令）會導(dǎo)致一個或多個扇區(qū)請求，這是硬件處理的實際內(nèi)存訪問單元。每個扇區(qū)是 32 字節(jié)，因此每個線程一條 8 字節(jié)雙精度字的扭曲加載指令會導(dǎo)致 8 個扇區(qū)請求（訪問以單位跨距進(jìn)行），而一條雙精度字的扭曲加載指令會導(dǎo)致 16 個扇區(qū)請求。普通負(fù)載和寬負(fù)載的扇區(qū)請求總數(shù)相同。那么，是什么導(dǎo)致了性能的提高呢？

為了理解代碼行為，我們需要考慮一個尚未討論的資源，即寄存器。這些用于存儲從內(nèi)存加載的數(shù)據(jù)，并用作算術(shù)指令的輸入。寄存器是一種有限的資源。如果流式多處理器（ SM ）在 A100 GPU 上承載盡可能多的扭曲，則每個線程可以使用 32 個 4 字節(jié)寄存器，這些寄存器總共可以容納 16 個雙精度字。將代碼翻譯成機(jī)器語言的編譯器知道這一點，并將限制每個線程的寄存器數(shù)量。我們?nèi)绾未_定代碼的寄存器使用及其在性能中所起的作用？我們使用 Nsight Compute 中的“ source ”視圖來并排查看匯編代碼（“ SASS ”）和 C 源代碼。

代碼的最內(nèi)層循環(huán)是執(zhí)行次數(shù)最多的循環(huán)，因此，如果我們在導(dǎo)航菜單中選擇“已執(zhí)行的指令”，然后要求轉(zhuǎn)到 SASS 代碼中數(shù)量最多的那一行，我們會自動進(jìn)入內(nèi)部循環(huán)。如果不確定，可以將 SASS 與突出顯示的相應(yīng)源代碼進(jìn)行比較以確認(rèn)。接下來，我們在內(nèi)環(huán)的 SASS 代碼中識別從內(nèi)存（ LDG ）加載數(shù)據(jù)的所有指令。圖 2 顯示了 SASS 的一個片段，我們在其中搜索以找到內(nèi)部循環(huán)的開始；在第 166 行，指令的執(zhí)行次數(shù)突然跳到其最大值。

圖 2 ：演示內(nèi)部循環(huán)開始的 SASS 代碼段（第 166 行）

LDG 。 E 、 64 是我們所追求的指令。它從全局內(nèi)存（ DRAM ）加載一個具有擴(kuò)展地址的 64 位字。寬單詞的負(fù)載對應(yīng)于 LDG 。 E 、 128 。加載指令名稱后的第一個參數(shù)（圖 2 中的 R34 ）是接收該值的寄存器。由于雙精度值占用兩個相鄰寄存器，因此加載指令中隱含 R35 。接下來，我們比較三個版本的代碼（ 1.基線， 2.寬負(fù)載的small_array， 3.寬負(fù)載的small_array和big_array）在內(nèi)部循環(huán)中使用寄存器的方式。回想一下，編譯器試圖保持在限制范圍內(nèi)，有時需要對寄存器進(jìn)行處理。也就是說，如果沒有足夠的寄存器可用于從內(nèi)存接收每個唯一值，它將重用以前在內(nèi)部循環(huán)中使用的寄存器。

這樣做的結(jié)果是，算術(shù)指令需要使用以前的值，以便新值可以覆蓋它。此時，從內(nèi)存加載需要等待該指令完成：內(nèi)存延遲暴露。在所有現(xiàn)代計算機(jī)體系結(jié)構(gòu)上，此延遲構(gòu)成了一個顯著的延遲。在 GPU 上，可以通過切換到另一個扭曲來隱藏部分扭曲，但通常不是全部扭曲。因此，寄存器在內(nèi)環(huán)中被重用的次數(shù)可以表示代碼的速度變慢。

有了這一見解，我們分析了代碼的三個版本，發(fā)現(xiàn)它們在每個內(nèi)部循環(huán)中分別經(jīng)歷了 8 、 6 和 3 個內(nèi)存延遲，這解釋了圖 1 所示的性能差異。不同寄存器重用模式背后的主要原因是，當(dāng)兩個普通加載融合為單個寬加載時，通常需要更少的地址計算，并且地址計算的結(jié)果也會進(jìn)入寄存器。隨著持有地址的寄存器越來越多，剩下來充當(dāng)從內(nèi)存中提取的值的“著陸區(qū)”的地址越來越少，我們在 Music chairs 游戲中失去了席位；寄存器壓力增大。

第三步：啟動邊界

我們還沒有完成?，F(xiàn)在我們知道了寄存器在程序性能中所起的關(guān)鍵作用，我們將查看三個版本的代碼使用的寄存器總數(shù)。最簡單的方法是再次檢查 Nsight Compute 報告。我們發(fā)現(xiàn)使用的寄存器數(shù)量分別為 40 、 36 和 44 。

編譯器確定這些數(shù)字的方法是使用復(fù)雜的啟發(fā)式算法，該算法考慮了大量因素，包括 SM 上可能存在多少活動扭曲、在忙循環(huán)中加載的唯一值的數(shù)量以及每個操作所需的寄存器數(shù)量。如果編譯器不知道 SM 上可能存在的扭曲數(shù)，它將嘗試將每個線程的寄存器數(shù)限制為 32 ，因為如果存在硬件允許的絕對最大同時扭曲數(shù)（ 64 ），那么這就是可用的數(shù)字。在我們的例子中，我們沒有告訴編譯器期望的是什么，所以它盡了最大努力，但顯然確定僅使用 32 個寄存器生成的代碼效率太低。

然而，內(nèi)核的 launch 語句中指定的線程塊的實際大小是 1024 個線程，因此有 32 個扭曲。這意味著，如果 SM 上只存在一個線程塊，則每個線程最多可以使用 64 個線程。在實際使用的每個線程中有 40 、 36 和 44 個寄存器時，沒有足夠的寄存器可用于支持每個 SM 的兩個或多個線程塊，因此將只啟動一個，每個線程分別保留 24 、 28 和 20 個未使用的寄存器。

通過使用 launch bounds 將我們的意圖告知編譯器，我們可以做得更好。通過告訴編譯器一個線程塊中的最大線程數(shù)（ 1024 ）和同時支持的最小塊數(shù)（ 1 ），編譯器可以放松，并且很高興每個線程分別使用 63 、 56 和 64 個寄存器。

有趣的是，最快的代碼版本現(xiàn)在是基線版本，沒有任何廣泛的負(fù)載。雖然組合寬負(fù)載 without 啟動邊界的加速比為 1.64 倍，但寬負(fù)載 with 啟動邊界的加速比為 1.76 倍，而基線代碼的加速比為 1.77 倍。這意味著我們不必費心修改內(nèi)核定義；在這種情況下，僅提供啟動邊界就足以獲得這種特定線程塊大小的最佳性能。

通過對 SM 上的線程塊大小和預(yù)期的最小線程塊數(shù)進(jìn)行更多的實驗，我們在每個 SM 有 512 個線程的 2 個線程塊的情況下達(dá)到了 1.79 倍的加速，對于沒有寬負(fù)載的基線版本也是如此。

結(jié)論

寄存器的有效使用對于獲得良好的 GPU 內(nèi)核性能至關(guān)重要。有時，一種稱為“寬負(fù)載”的技術(shù)可以帶來顯著的好處。它減少了計算并需要存儲在寄存器中的內(nèi)存地址的數(shù)量，留下更多的寄存器來接收來自內(nèi)存的數(shù)據(jù)。然而，向編譯器提示在應(yīng)用程序中啟動內(nèi)核的方式可能會帶來同樣的好處，而無需更改內(nèi)核本身。

關(guān)于作者

Rob Van der Wijngaart 是 NVIDIA 的高級高性能計算（ HPC ）架構(gòu)師。他在各種工業(yè)和政府實驗室從事 HPC 領(lǐng)域的研究超過三十年，是廣泛使用的 NAS 并行基準(zhǔn)測試的共同開發(fā)者。

Fred Oh 是 CUDA 、 CUDA on WSL 和 CUDA Python 的高級產(chǎn)品營銷經(jīng)理。弗雷德?lián)碛屑又荽髮W(xué)戴維斯分校計算機(jī)科學(xué)和數(shù)學(xué)學(xué)士學(xué)位。他的職業(yè)生涯開始于一名 UNIX 軟件工程師，負(fù)責(zé)將內(nèi)核服務(wù)和設(shè)備驅(qū)動程序移植到 x86 體系結(jié)構(gòu)。

審核編輯：郭婷