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

第二步：寄存器使用

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

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

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

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

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

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

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

第三步：?jiǎn)?dòng)邊界

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

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

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

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

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

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

結(jié)論

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

關(guān)于作者

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

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

審核編輯：郭婷