這一系列文章面向CUDA開發(fā)者來解讀《CUDA C?

Best Practices Guide》 (CUDA C最佳實(shí)踐指南)

大家可以訪問：

這是一本很經(jīng)典的手冊(cè)。

CUDA優(yōu)化的冷知識(shí)|什么是APOD開發(fā)模型？

CUDA優(yōu)化的冷知識(shí)2| 老板對(duì)不起

CUDA優(yōu)化的冷知識(shí) 3 |男人跟女人的區(qū)別

CUDA優(yōu)化的冷知識(shí) 4 | 打工人的時(shí)間是如何計(jì)算的

CUDA優(yōu)化的冷知識(shí) 5 | 似是而非的計(jì)時(shí)方法

CUDA優(yōu)化的冷知識(shí) 6 |GPU端的CUDA Event計(jì)時(shí)

CUDA優(yōu)化的冷知識(shí) 7 |GPU端Event計(jì)時(shí)的重要特色

CUDA優(yōu)化的冷知識(shí) 8 |GPU顯存的特色

CUDA優(yōu)化的冷知識(shí)9 |GPU顯存的粒度

我們下面就繼續(xù)進(jìn)一步的, 說說Global Memory的相關(guān)優(yōu)化.

要說對(duì)它的優(yōu)化, 我們得先知道Global Memory是什么, 和很多人的印象里的不同, 它不一定是顯存. 還可能是映射的內(nèi)存. (例如zero-copy時(shí)候的手工分配的, 和退化的Unified Memory的情況). 我們主要說一下當(dāng)Global Memory是顯存, 和是zero-copy的情況, 而暫時(shí)忽略是退化的Unified Memory的情況。

說一下這兩者時(shí)候的注意事項(xiàng)和優(yōu)化.

首先本實(shí)踐手冊(cè)這里, 提到了zero-copy內(nèi)存, 這種是鎖定在物理頁面中, 而不能被交換到磁盤上, 同時(shí)又能被GPU設(shè)備, 直接訪問到的內(nèi)存(映射成了global memory)。

這種內(nèi)存, 具有多個(gè)特點(diǎn).

先說一下實(shí)體顯卡上的, 再說一下我們的Jetson上的。

在實(shí)體顯卡上, 因?yàn)榭ㄊ峭ㄟ^PCI-E連接到CPU的, 此時(shí)的一切傳輸(從內(nèi)存到顯存), 均需要通過PCI-E進(jìn)行. 而PCI-E的帶寬非常有限. 通常只有16GB/s的理論帶寬. 注意手冊(cè)這里第一次給出了實(shí)際能達(dá)到的, 在PCI-E 3.0 x16下的傳輸帶寬, 往往是只有12GB/s左右, 這個(gè)結(jié)果是和實(shí)際日常使用中的情況是一樣的. 手冊(cè)這里給出的的確是比較準(zhǔn)確的數(shù)字. 而這個(gè)帶寬, 很多時(shí)候, 只有通過鎖定在頁面中的緩沖區(qū)傳輸, 才能達(dá)到的, 為何? 主要是這個(gè)涉及了CUDA C編程指南中, 和CUDA Runtime API手冊(cè)中的最前面說的一些情況. 我簡(jiǎn)單這里重復(fù)一下吧.

一個(gè)是作為PCI-E上的GPU設(shè)備, 他用自帶的DMA引擎, 進(jìn)行BUS Mastering的時(shí)候, 本身就只能訪問物理頁面(或者說, 物理頁面范圍). 而不能支持CPU端的虛擬內(nèi)存. (否則它將需要理解CPU端的頁表結(jié)構(gòu)等一系列問題, 才能自動(dòng)轉(zhuǎn)換)。我們知道當(dāng)年的某藍(lán)色巨人的XGA顯卡, 作為它的8514顯卡的繼承人, 具有CPU端的虛擬內(nèi)存支持, 并重新實(shí)現(xiàn)了兼容于x86 CPU的頁表和相應(yīng)的CR寄存器，作為當(dāng)年的該機(jī)型的用戶, 超越了20年的感動(dòng)依然在心中。然而其他所有后來的顯卡都沒有這個(gè)特點(diǎn), 因此他們就只能用自己的DMA Engines訪問物理內(nèi)存(好吧, 某些DGX例外). 因此, 當(dāng)用戶要求傳輸一段普通的可換頁內(nèi)存的時(shí)候, 要么顯卡驅(qū)動(dòng)內(nèi)部, 先將該段內(nèi)存緩沖區(qū)的內(nèi)容, 復(fù)制到自己內(nèi)部的一個(gè)小的鎖定的物理頁面范圍上去, 然后再?gòu)倪@里安全的傳輸; 要么就是就地嘗試鎖定, 然后傳輸. 但前者多了一次內(nèi)存內(nèi)存的傳輸, 后者則有鎖定和解鎖開銷(這里面的細(xì)節(jié)可以看CUDA Runtime API手冊(cè)的前面, 歷年GTC也有過詳細(xì)描述) 。

前者幾乎將內(nèi)存的有效帶寬降低了一半，例如我們上次距離的那個(gè)68GB/s峰值的內(nèi)存的機(jī)器(4通道DDR4-2133), 這樣一倒騰, 內(nèi)存帶寬就實(shí)際上只有34GB/s了. 哪怕你不考慮在CPU上運(yùn)行的應(yīng)用程序的需要, 光這點(diǎn)帶寬, 傳輸兩三張卡就撐不住了，而使用這種鎖定了頁面的內(nèi)存, 則可以就地開始傳輸, 節(jié)省了一半的內(nèi)存的帶寬, 因?yàn)檫^程從內(nèi)存->內(nèi)存->顯存, 變成了內(nèi)存->顯存了. 還是很容易喂飽你的卡們的. 這個(gè)是很適合在實(shí)體GPU上傳輸?shù)奶匦浴?/p>

這是對(duì)于實(shí)體卡說的，對(duì)于我們的Jetson產(chǎn)品, 實(shí)際上是并沒有獨(dú)立的顯存和內(nèi)存的, 也不是通過PCI-E總線傳輸?shù)? CPU和GPU都在SoC的內(nèi)部, 共享SoC提供的內(nèi)存(顯存)控制器. 此時(shí)如果你照搬之前的經(jīng)驗(yàn), 直接來一個(gè)cudaMemcpy*()系列函數(shù). 則實(shí)際上你無辜的在該內(nèi)存(顯存)內(nèi)部, 倒騰了一次. 無任何意義. 當(dāng)時(shí)他們提出, 一定要利用頁面鎖定內(nèi)存, 能無傳輸?shù)木偷卦L問的特性(俗稱zero-copy, 可以看成是最最簡(jiǎn)化版的Unified Memory). 取消掉這個(gè)在Jetson上的無辜傳輸. 然后讓GPU就地訪問CPU的工作數(shù)據(jù). 這點(diǎn)還是非常重要的。

不過在Jetson系列產(chǎn)品上, 直接使用zero-copy的方式會(huì)禁用GPU的緩存(L2)的, 不如后來的更好用一點(diǎn)(但限制更大)的Jetson上的Unified Memory方式好(也是直接共享, 但啟用L2, 但會(huì)禁用CPU-GPU同時(shí)訪問). 這點(diǎn)等我們到了Unified Memory的時(shí)候再說。

好了．回到本章節(jié)前面的頁面鎖定內(nèi)存的傳輸和作為zero-copy上的特性內(nèi)容。

注意本章節(jié)這里提到了, 要在CUDA 2.2+, 無顯存的那種集成顯卡上, 使用zero-copy, 云云的. 而沒有提到Jetson. 這是因?yàn)槭謨?cè)10年來沒改的緣故了.

我們現(xiàn)在已經(jīng)將近10年買不到這種無顯存的卡了(以前一些筆記本上有)，而Jetson產(chǎn)品也已經(jīng)普及。

所以我們這里做了調(diào)整, 取消了手冊(cè)上說的過時(shí)的不存在的內(nèi)容, 而增加了Jetson上應(yīng)當(dāng)考慮zero-copy就地使用的做法.

此外, 手冊(cè)上介紹了如何能利用頁面鎖定的內(nèi)存, 有效的進(jìn)行計(jì)算和傳輸重疊的特性. 手冊(cè)這里給出了一個(gè)很好用的東西:

就是當(dāng)我們只有1個(gè)kernel要啟動(dòng), 和1份緩沖區(qū)要使用的時(shí)候, 如果能讓這個(gè)進(jìn)行多次傳輸和計(jì)算的重疊. 本實(shí)踐手冊(cè)這里給出了如下建議: 即將你的kernel修改里面的線程或者block的坐標(biāo)/下標(biāo)映射, 將原本一次啟動(dòng)的kernel, 工作于一個(gè)大緩沖區(qū)上, 改成N次啟動(dòng)(注意每次里面的坐標(biāo)的變化), 并每次傳輸1/N內(nèi)容的緩沖區(qū), 這樣可以盡量達(dá)到傳輸和計(jì)算的重疊. 這個(gè)是一個(gè)很好的實(shí)踐方式. 因?yàn)楹芏鄷r(shí)候, 你想利用傳輸和計(jì)算重疊這個(gè)優(yōu)化, 但是你找不到多余的kernel計(jì)算任務(wù), 和多余的傳輸任務(wù)來重疊，此時(shí), 你應(yīng)當(dāng)考慮本手冊(cè)中的, 拆分計(jì)算規(guī)模, 和拆分成1/N每次傳輸?shù)慕ㄗh. 這種建議還是很好的. 當(dāng)然這樣做, 你需要注意坐標(biāo)的偏移和變化. 不要計(jì)算錯(cuò)了.

實(shí)際上, 在某OpenCL對(duì)等的規(guī)范中, 在友商家的卡上, 我們可以直接在啟動(dòng)kernel的時(shí)候, 提供這個(gè)坐標(biāo)偏移量. 從而完成類似的操作, 而不需怎么改動(dòng)代碼. 所以你看, 這是一個(gè)相當(dāng)實(shí)用的東西, 實(shí)用到友商家已經(jīng)提供了API以方便你這樣做了.

此外, 手冊(cè)還提供了另外一個(gè)建議, 就是直接不要傳輸了, 直接就地使用. 因?yàn)閦ero-copy可以以一定的粒度, 直接從內(nèi)存跨越PCI-E到L2(然后進(jìn)一步到SM中). 這樣根據(jù)手冊(cè)這里的說法, 能在kernel的指令級(jí)別, 實(shí)現(xiàn)計(jì)算和傳輸?shù)闹丿B. 但是根據(jù)我們的實(shí)踐, 大部分的使用效果實(shí)際上并不好. 我們懷疑是可能是跨越PCI-E帶來了更大更難掩蓋的延遲或者其他因素, 這些需要等待確定. 但是手冊(cè)中不強(qiáng)調(diào)的另外一個(gè)用法, 實(shí)際上效果非常好. 即將zero-copy作為容納結(jié)果數(shù)據(jù)的, 寫入的緩沖區(qū). 這種可以將結(jié)果的回傳, 和kernel的計(jì)算, 也在kernel的指令級(jí)別, 進(jìn)行重疊. 而無需你事后開一個(gè)異步傳輸在某流中. 在我們的日常實(shí)踐中, 這種具有非常好的使用效果. 好到了很多人都發(fā)現(xiàn)了這點(diǎn). 并且在arvix上發(fā)文, 用FPGA攔截了zero-copy作為寫入結(jié)果的緩沖區(qū)的時(shí)候, kernel的寫入, 在指令級(jí)別的重疊, 通過L2, 跨越PCI-E回傳的時(shí)候的情況, 并做了分析. 我們現(xiàn)在大致知道, 根據(jù)此文(我不記得番號(hào)了, 但是容易找到. 用FPGA + Zero-Copy的字樣, 近期文章),

手冊(cè)中的這種作為直接回寫操作的做法, L2會(huì)產(chǎn)生跨越PCI-E的32B, 64B, 128B大小的傳輸?shù)?

然后本文章還分析了, 為何只能達(dá)到約12GB/s, out of 16GB/s的原因(因?yàn)镻CI-E的包大小的問題的浪費(fèi), 而不是編碼問題). (注意這是說的PCI-E 3.0, 而不是4.0, 后者可能大約達(dá)到25GB/s, 這是根據(jù)我們客戶的反饋, 而不是實(shí)際我們的測(cè)試).

大致是分析完了顯存的特性、一個(gè)令人意外的(非常分散的不合并讀寫的優(yōu)勢(shì))、 兩種global memory中的前一種, 以及它的傳輸上的好用的地方, 和在Jetson上的應(yīng)用。

總結(jié)

以上是生活随笔為你收集整理的cuda第一次计算耗时_CUDA优化的冷知识10 | GPU卡和Jetson上显存优化的特色的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。