圖 1 ：由于負載較寬，內核持續時間減少

第二步：寄存器使用

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

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

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

圖 2 ：演示內部循環開始的 SASS 代碼段（第 166 行）

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

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

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

第三步：啟動邊界

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

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

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

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

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

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

結論

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

關于作者

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

Fred Oh 是 CUDA 、 CUDA on WSL 和 CUDA Python 的高級產品營銷經理。弗雷德擁有加州大學戴維斯分校計算機科學和數學學士學位。他的職業生涯開始于一名 UNIX 軟件工程師，負責將內核服務和設備驅動程序移植到 x86 體系結構。

審核編輯：郭婷