拿到一個運行緩慢的 CUDA 內(nèi)核許多人的第一反應(yīng)是“多加線程”“把循環(huán)展開”結(jié)果通常是越調(diào)越玄學(xué)。真正讓我從玄學(xué)轉(zhuǎn)向可量化的是反復(fù)使用 Nsight Compute 拉指標(biāo)把 GPU 內(nèi)核的每一步執(zhí)行拆開來看。Nsight Compute 是 NVIDIA 官方推出的內(nèi)核級性能分析工具針對單個 CUDA kernel 做深度 profiling可以輸出 SM 利用率、內(nèi)存吞吐、Warp 狀態(tài)、指令發(fā)射情況等底層指標(biāo)。它解決的問題很明確當(dāng)你覺得某段 GPU 代碼沒有發(fā)揮出硬件全部實力時幫助你判斷瓶頸到底在計算單元、內(nèi)存帶寬、訪存延遲還是調(diào)度開銷。適合所有寫 CUDA、OpenCL 或做 GPU 計算優(yōu)化的同學(xué)尤其是 kernel 調(diào)優(yōu)時不知道從哪里入手的人。這篇內(nèi)容我是基于實際項目里的調(diào)優(yōu)經(jīng)歷寫的。文章不會停留在“打開工具看一眼”的層面而是把 Nsight Compute 中最常用的一批指標(biāo)逐個講清楚它們叫什么、算的是什么、數(shù)值高低意味著什么、能指引你做什么優(yōu)化。全部都是可以直接復(fù)用到你自己項目里的東西。1. 先搞清楚 Nsight Compute 到底在測什么1.1 它和 Nsight Systems 的分工我最早踩過的一個坑是把 Nsight Systems 當(dāng)成萬能工具盯著 GPU Utilization 看了半天發(fā)現(xiàn)“GPU 很忙”但 kernel 依然很慢。后來才明白Systems 和 Compute 是兩個層級完全不同的工具。用一句話概括分工Nsight Systems 是應(yīng)用級/系統(tǒng)級性能分析器負(fù)責(zé)看全局時間線、CPU 與 GPU 的同步點、API 調(diào)用開銷、內(nèi)存拷貝耗時它解決的是“整個程序的時間都花在哪了”Nsight Compute 則是內(nèi)核級分析器把一個 kernel 放進(jìn)“顯微鏡”里逐個 SM、逐條指令地分析硬件計數(shù)器解決的是“這個 kernel 為什么沒有跑滿硬件”。實際使用中我通常先把程序丟給 Systems 看整體分布確認(rèn)某個 kernel 確實占用大量時間再切換到 Nsight Compute 對這一個 kernel 做深度剖析。兩者是接力關(guān)系不是替代關(guān)系。這也解釋了很多人的困惑為什么我用 Systems 看不出某個 kernel 內(nèi)部的指令效率問題因為它本來就不管那么細(xì)。1.2 它的核心分析邏輯三層遞進(jìn)Nsight Compute 的分析邏輯我用了幾年后總結(jié)成三層遞進(jìn)第一層先看 kernel 有沒有達(dá)到硬件極限對應(yīng)的是 Speed Of LightSOL分析頁面類似體檢報告的總評。第二層如果沒達(dá)到極限判斷它卡在哪類資源上是計算單元飽和了、內(nèi)存帶寬打滿了、還是延遲掩蓋不足。第三層結(jié)合 Warp Stall 原因、指令統(tǒng)計、源碼關(guān)聯(lián)定位到具體代碼行或者某條指令。這個邏輯非常像醫(yī)生看病SOL 是給你量體溫、測血壓確認(rèn)“有問題”資源分析是拍 CT看具體哪塊組織異常Warp 狀態(tài)和指令級指標(biāo)就是穿刺活檢鎖定病灶。你不需要每次都走到第三層但前兩層基本是每次 profiling 必看的。很多新手容易犯的錯誤是打開 Nsight Compute 后一頭扎進(jìn)某個生僻指標(biāo)里埋頭研究。建議從一開始就按照三層遞進(jìn)的路子走先從宏觀判斷方向再逐步下鉆。如果第一層已經(jīng)告訴你“所有關(guān)鍵資源都滿負(fù)荷了”那就說明 kernel 已經(jīng)逼近硬件上限優(yōu)化空間主要在算法層面而不是微調(diào)指令。2. 最關(guān)鍵的一批指標(biāo)SM 利用率與 Speed Of Light2.1 SM Active Warps 和利用率到底看哪個“SM 利用率”這個詞其實很籠統(tǒng)NVIDIA 官方指標(biāo)里真正值得關(guān)注的是 Achieved Active Warps Per Scheduler也就是每個調(diào)度器上實際活躍的 warp 數(shù)量。GPU 硬件的執(zhí)行單位是 warp一個 warp 是 32 個線程調(diào)度器負(fù)責(zé)把 warp 派發(fā)給對應(yīng)的執(zhí)行單元。以 A100 為例每個 SM 有 4 個 warp scheduler每個 scheduler 最多管理 16 個 warpSM 層面最大同時駐留 64 個 warp。Nsight Compute 會把這個數(shù)量以平均活躍 warp 數(shù)的形式展示出來再除以理論最大值得到一個百分比。這個百分比反映的是“硬件上有多少并行任務(wù)可以被調(diào)度器拿來填滿流水線”。如果 Achieved Occupancy 只有 30%那么即使計算單元規(guī)格再高也可能因為可用 warp 太少而無法隱藏延遲導(dǎo)致很多執(zhí)行單元在空轉(zhuǎn)等待。反過來說如果這個數(shù)值已經(jīng)接近 90% 以上說明 SM 層面已經(jīng)塞得很滿這時候性能瓶頸大概率不在占用率而在具體的執(zhí)行流水線或內(nèi)存子系統(tǒng)。2.2 SOL 分析圖怎么看顏色和柱狀圖SOL 頁面是 Nsight Compute 里最直觀也最容易被誤讀的部分。它分為兩個主區(qū)域Compute Workload Analysis 和 Memory Workload Analysis。每個區(qū)域里會展示對應(yīng)硬件單元比如 FMA 管線、ALU 管線、LSU 管線、L1/TEX 緩存、L2 緩存、DRAM的利用率百分比。顏色越深代表利用率越高深紅色基本表示對應(yīng)硬件已經(jīng)接近滿負(fù)荷運行也就是當(dāng)前瓶頸所在淺色則表示資源大部分時間在空閑。這個設(shè)計非常像 CPU 調(diào)優(yōu)里的 hotspot 分析你只需要第一時間找出“最深的那根柱子”。注意一個細(xì)節(jié)SOL 圖中的百分比都是相對“峰值理論性能”計算的不同硬件架構(gòu)的峰值定義不同。所以不要拿著 A100 的 SOL 數(shù)據(jù)去對照 V100 或者 RTX 3090 的絕對值跨架構(gòu)比較意義不大。重要的是看你自己這個 kernel 在不同硬件單元之間的相對關(guān)系。2.3 判斷計算密集還是內(nèi)存密集SOL 頁面最核心的用途是快速判斷一個 kernel 到底是 compute-bound 還是 memory-bound。如果在 Compute Workload Analysis 中FMA Pipe 或者 ALU Pipe 利用率已經(jīng)到 90% 以上而右側(cè) Memory Workload Analysis 里的 DRAM 利用率只有 20%那么這是一個典型的計算密集 kernel。優(yōu)化方向應(yīng)該放在減少冗余計算、提高指令級并行、考慮使用更快的數(shù)學(xué)指令如 __fdividef、fast math等。反過來如果 DRAM 吞吐已經(jīng)頂?shù)浇咏鼛捝舷薅髠?cè) SM 計算單元利用率普遍不到 50%那就是內(nèi)存帶寬瓶頸。此時最有效的優(yōu)化是改善訪存合并、提高數(shù)據(jù)復(fù)用、增加 L2 命中率、分塊處理數(shù)據(jù)等。千萬不要在 memory-bound 的 kernel 上花大量時間去摳指令重排那是南轅北轍。還有一個容易被忽略的中間態(tài)既不是計算密集也不是帶寬密集而是延遲密集。表現(xiàn)為 SOL 兩側(cè)利用率都不高SM 計算單元和內(nèi)存都沒打滿但 Achieved Occupancy 偏低、Warp State 里占滿 Long Scoreboard 等待。這種情況靠增加并行度來掩蓋延遲通常是第一優(yōu)先級。3. Occupancy、Warp Stall 與指令級指標(biāo)3.1 Occupancy 別被它騙了Occupancy 是 Nsight Compute 里最常被引用的指標(biāo)之一但我越來越傾向于提醒別人它重要但不是越高越好。從定義上看Achieved Occupancy 是“每個 SM 上同時駐留的實際 warp 數(shù) / SM 最大可駐留 warp 數(shù)”。這個數(shù)值高意味著 SM 里“排隊等待”的 warp 多調(diào)度器有更多選擇來隱藏各種延遲。數(shù)值低則往往意味著硬件資源沒有被填滿。但高 Occupancy 不一定帶來高性能。舉個例子一個純計算密集的 kernel每個線程需要大量寄存器。如果為了強行提高 Occupancy 而把 block 尺寸調(diào)小以匹配寄存器數(shù)量反而可能導(dǎo)致每個線程可用寄存器不足產(chǎn)生 register spilling寄存器溢出到 local memory。local memory 物理上是放在全局內(nèi)存里的訪問速度比寄存器慢幾個數(shù)量級性能損失遠(yuǎn)大于 Occupancy 提升帶來的收益。Nsight Compute 的 GUI 里提供了 Launch Configuration 分析可以交互式調(diào)整 block size、grid size、共享內(nèi)存分配量預(yù)覽 Occupancy 變化。我每次調(diào) launch 參數(shù)都會先用這個頁面預(yù)估一下確認(rèn)不會觸發(fā)寄存器溢出再實際編譯測試。3.2 Warp State 里的 Stall 原因怎么讀懂Warp State 統(tǒng)計是 Nsight Compute 里信息密度最高、也最難快速上手的部分。它統(tǒng)計的是每個 warp 在周期內(nèi)的狀態(tài)分布核心看點是 Stall 原因——也就是為什么 warp 沒有處于可執(zhí)行狀態(tài)。常見 Stall 原因按我的經(jīng)驗排序如下Long Scoreboard等待全局訪問返回這是最常見的 stall幾乎總是跟內(nèi)存延遲相關(guān)。Short Scoreboard等待共享內(nèi)存、常量內(nèi)存或紋理訪問返回延遲較低。Barrier等待同一個 block 內(nèi)的其他 warp 到達(dá)同步點。Wait固定周期延遲例如 __syncwarp 或依賴鏈中的固定等待。Not Selected這個 warp 本身可執(zhí)行只是調(diào)度器選擇先派發(fā)其他 warp。其中 Not Selected 占比高其實是好事說明調(diào)度器有其他 warp 可以執(zhí)行當(dāng)前 warp 只是暫時沒有被選中。真正需要警惕的是 Long Scoreboard 和 Barrier 占比過高前者代表訪存延遲沒被掩蓋后者代表線程間同步粒度太粗。我在實際優(yōu)化中遇到 Barrier 占比過高的場景通常會在滿足正確性的前提下盡量壓縮同步區(qū)域或者用粗粒度任務(wù)劃分代替細(xì)粒度同步讓不同 block 各干各的。遇到 Long Scoreboard 占比高則優(yōu)先考慮提高 Occupancy 或者改用更寬松的訪存模式。3.3 寄存器、local memory 與共享內(nèi)存的指標(biāo)Nsight Compute 的 Resource Usage 區(qū)塊會直接列出 Register Usage、Local Memory Usage、Shared Memory Usage 三項關(guān)鍵信息。寄存器使用量直接決定 Occupancy 上限這是很多優(yōu)化決策的起點。比如 A100 上每個 SM 的寄存器文件是 65536 個 32 位寄存器如果每個線程用 128 個寄存器那么一個 SM 最多駐留 512 個線程約 16 個 warp對應(yīng) Occupancy 上限就壓到 25% 左右。如果這時 kernel 又是延遲敏感的性能就會很難看。Local Memory 使用量是我每次必看的指標(biāo)。如果編譯器報告每個線程使用了較多 local memory基本說明寄存器溢出發(fā)生了。優(yōu)化手段包括減少每個線程的私有數(shù)組大小、把大數(shù)組移到共享內(nèi)存、降低寄存器壓力用 launch bounds 限定最大線程數(shù)。切忌直接忽略這個指標(biāo)它是性能殺手。共享內(nèi)存使用量則是一把雙刃劍。用得好可以極大減少全局內(nèi)存訪問比如矩陣分塊、卷積數(shù)據(jù)復(fù)用場景用太多則會限制每個 SM 上并發(fā) block 的數(shù)量間接壓低 Occupancy。我傾向于先確認(rèn)瓶頸是全局帶寬還是 Occupancy再決定是否值得加大共享內(nèi)存開銷。4. 內(nèi)存指標(biāo)詳解帶寬、延遲與訪問模式4.1 Memory Throughput 不只是看 DRAM很多人一談內(nèi)存指標(biāo)就只盯 DRAM 利用率這是不對的。Nsight Compute 的 Memory Workload Analysis 會同時報告 L1/TEX 緩存、L2 緩存和 DRAM 的吞吐數(shù)據(jù)。這三層需要結(jié)合起來看。比如一個 kernel 的 L2 命中率很高那么 DRAM 利用率低并不代表訪存沒問題因為真正服務(wù)處理的是 L2 緩存。如果 L1 命中率很低、L2 命中率很高說明數(shù)據(jù)在 L1 這一層基本沒有復(fù)用每次訪問都要從 L2 拿L2 的帶寬壓力很大。如果 L1 和 L2 命中率都低那基本可以確定全局訪存是海量且無規(guī)律的大規(guī)模讀取DRAM 吞吐被打滿只是早晚的事。我的經(jīng)驗是每次先記錄三個數(shù)字——L1 命中率、L2 命中率、DRAM 利用率再看它們之間的組合關(guān)系。L1 命中率低但 L2 命中率尚可重點優(yōu)化線程塊內(nèi)的數(shù)據(jù)復(fù)用L2 命中率也低重點優(yōu)化數(shù)據(jù)分塊和訪問模式。4.2 全局加載/存儲效率合并訪問的量化體現(xiàn)全局訪問合并coalescing是 GPU 性能優(yōu)化的基本功。Nsight Compute 中可以通過 Memory Workload Analysis 里的 Sector/Transaction 統(tǒng)計來量化合并程度。一個 warp 訪問 32 個線程對應(yīng)的地址如果這 32 個地址恰好落在連續(xù)的 32 字節(jié) sector 里硬件只需要發(fā)起極少的 memory transaction如果地址分散在不同頁面transaction 數(shù)量會成倍增加造成帶寬浪費。比較直觀的量化方式是看 Global Load Efficiency 或者類似指標(biāo)。如果效率只有 25%說明實際發(fā)生了大量冗余訪問相當(dāng)于每 4 個字節(jié)的有效數(shù)據(jù)搬運了 16 個字節(jié)。修復(fù)辦法通常是調(diào)整數(shù)據(jù)布局盡量保證一個 warp 內(nèi)相鄰線程訪問相鄰地址或者改用 float4、double2 等向量化訪存指令一次取多個連續(xù)數(shù)據(jù)。我在優(yōu)化一個粒子模擬項目時就把自定義結(jié)構(gòu)體的 SoAStructure of Arrays布局從簡單指針改成 float4 對齊的向量訪問Global Load Efficiency 從 30% 直接拉到 90% 以上整個 kernel 快了接近 3 倍。這就是合并訪問的威力。4.3 L1/L2 命中率與數(shù)據(jù)復(fù)用模式緩存命中率往往被當(dāng)作“順手看一眼”的輔助指標(biāo)實際上它決定了內(nèi)存帶寬瓶頸的嚴(yán)重程度。在 Nsight Compute 中L1 命中率以及 L2 命中率都可以在 Memory Workload Analysis 里看到。如果命中率偏低我的建議是先審視數(shù)據(jù)的復(fù)用模式而不是急著加 __ldg 或者 const restrict。比如矩陣乘法里的 tiled 分塊就是最經(jīng)典的通過 shared memory 顯式復(fù)用數(shù)據(jù)來抬高緩存收益的方案。再比如卷積網(wǎng)絡(luò)的前向計算用滑動窗口的方式訪問輸入數(shù)據(jù)同一個輸入像素會被多個輸出位置使用這時如果按行緩存到 shared memoryL1 命中率會明顯提升。還有一個技巧是觀察波前wavefront級別的行為。如果 grid 的 block 數(shù)量遠(yuǎn)大于 SM 數(shù)量每個 SM 會先后執(zhí)行多波。當(dāng)?shù)诙?block 啟動時第一波留下的 L2 緩存數(shù)據(jù)可能已經(jīng)被換出。這時可以嘗試調(diào)整 block 的調(diào)度順序或者讓每個 block 處理更連續(xù)的數(shù)據(jù)區(qū)間提高緩存利用率。4.4 L2 Cache 與 DRAM 之間的指標(biāo)聯(lián)動Nsight Compute 會把 L2 到 DRAM 之間的數(shù)據(jù)流動也暴露出來。比較核心的是 DRAM 讀取吞吐和寫入吞吐。寫入吞吐偏高時要注意是否有不必要的全局內(nèi)存寫入例如用 atomicAdd 頻繁更新全局計數(shù)器的場景或者反復(fù)在全局?jǐn)?shù)組上讀改寫。另一個值得關(guān)注的聯(lián)動指標(biāo)是“扇區(qū)訪問效率”。如果同一個緩存行只被用到其中一小部分?jǐn)?shù)據(jù)那么緩存行的大部分帶寬都浪費掉了。配合上一節(jié)講的合并訪問這個指標(biāo)可以幫你確認(rèn)數(shù)據(jù)布局是否需要調(diào)整。5. 實操過程一次完整的內(nèi)核 Profiling 流程5.1 最省事的命令行方式Nsight Compute 的命令行工具是 ncu。日常最常用的命令格式如下ncu --set full --launch-count 1 --launch-skip 3 ./my_application--set full表示收集所有類別的指標(biāo)信息最全但最慢。--launch-count 1表示只對第 4 次 kernel 啟動做數(shù)據(jù)收集。--launch-skip 3表示跳過前 3 次 kernel 啟動通常是 warmup 或初始化階段。如果程序里有很多 kernel只想分析某一個可以用-k參數(shù)按名字過濾例如ncu --set full -k my_kernel_name ./my_application還可以配合--csv --print-details all導(dǎo)出 CSV 文件方便后續(xù)用腳本做批量對比。我在做多組實驗對比時通常會把幾個關(guān)鍵指標(biāo)的 CSV 導(dǎo)出來用 pandas 簡單聚合省去手動抄數(shù)據(jù)的功夫。--metrics參數(shù)允許你只采集指定的少數(shù)指標(biāo)適合快速回歸測試。比如我想確認(rèn)優(yōu)化沒有影響 SM 利用率和運行時間可以只采集兩個指標(biāo)ncu --metrics sm__throughput.avg.pct_of_peak_sustained_elapsed,gpu__time_duration.sum ./my_application實測下來這種定向采集比--set full快非常多適合每次改完代碼后跑一遍做回歸。5.2 GUI 界面操作流程命令行適合批量腳本但 GUI 才是日常調(diào)優(yōu)的主戰(zhàn)場。NVIDIA Nsight Compute GUI 打開后在界面里配置 executable 路徑和參數(shù)選擇 profiling scope 為全量 Section點擊 Profile 即可。啟動后建議按以下順序過一遍第一打開 SOL 頁面看 Compute 和 Memory 兩側(cè)的柱狀圖記錄瓶頸類型。第二進(jìn)入 Occupancy 頁面看 Achieved Occupancy 是否明顯低于理論峰值并檢查 Register Usage 和 Shared Memory 是否成為限制因素。第三進(jìn)入 Warp State 頁面按 stall 原因排序確認(rèn)占比最高的是 Long Scoreboard、Barrier 還是 Wait。第四進(jìn)入 Memory Workload Analysis看 L1/L2 命中率、全局訪問效率、DRAM 吞吐。最后切換到 Source 或者 SASS 視圖把熱點指令關(guān)聯(lián)回具體代碼位置。這一步往往能直接指出是哪一行循環(huán)體里的訪存導(dǎo)致了 Long Scoreboard 占滿。5.3 優(yōu)化前后對比的正確姿勢做優(yōu)化前后對比時最容易犯的錯誤是只比較 wall time。Nsight Compute 本身在 profiling 態(tài)下會大幅拖慢 kernel 執(zhí)行因為它要轉(zhuǎn)儲大量硬件計數(shù)器所以它給出的時間絕對值不適合直接當(dāng)作基準(zhǔn)。正確做法是優(yōu)化前后都用相同的--metrics集合采樣硬件計數(shù)器對比 SM 利用率、DRAM 吞吐、L1/L2 命中率、Stall 分布這些相對穩(wěn)定的硬件指標(biāo)。只要硬件指標(biāo)顯示瓶頸被轉(zhuǎn)移或者消除再單獨用正常模式不帶 profiler跑三次取最短執(zhí)行時間或中位數(shù)時間做最終確認(rèn)。我個人的經(jīng)驗是硬件計數(shù)器的穩(wěn)定性遠(yuǎn)高于 wall clock在同一 GPU 上跑同一次 kernel計數(shù)器值基本是確定的。所以“指標(biāo)變了時間沒變”這種情況基本不會出現(xiàn)如果出現(xiàn)先懷疑 profiling 參數(shù)不一致或者 GPU 頻率波動太大。6. 常見問題與排查技巧實錄6.1 全量 profiling 太慢怎么辦全量收集所有 Section 的計數(shù)器Nsight Compute 需要對同一個 kernel 做多次重放每次只采集一組有限的計數(shù)器。kernel 本來就要跑幾十毫秒的全量 profiling 可能拖到幾十秒甚至幾分鐘這很正常。我的做法是分兩步走第一步先跑 SOL 快速剖面只收集最核心的 SOL 相關(guān)計數(shù)器確認(rèn)瓶頸方向。第二步根據(jù)方向選擇部分 Section 做深度采集。比如瓶頸在訪存就只開 Memory Workload Analysis 相關(guān)的 Section瓶頸在計算就開 Warp State 和 Instruction Statistics。全量采集盡量只用于最終確認(rèn)不要作為日常迭代手段。另外利用-c或--cache-control參數(shù)可以控制系統(tǒng)緩存的影響默認(rèn)情況下可能要求較高的權(quán)限。如果你在云主機或容器里跑建議先確認(rèn)設(shè)備訪問權(quán)限否則有些計數(shù)器會采不到。6.2 profiling 結(jié)果全是 0 或者指標(biāo)不可用這種情況我遇到過幾次基本都是環(huán)境問題。最常見的是 GPU 上沒有足夠權(quán)限訪問硬件計數(shù)器或者 profiling 目標(biāo)進(jìn)程被 GPU 優(yōu)先級搶占。解決辦法包括用 root 權(quán)限運行 ncu確認(rèn)沒有其他進(jìn)程占著 GPU比如桌面環(huán)境、其他訓(xùn)練任務(wù)盡量使用無顯示環(huán)境的 headless 模式。還有一種情況是 kernel 被編譯器優(yōu)化掉了比如空循環(huán)體導(dǎo)致數(shù)據(jù)根本不真實這種情況下對應(yīng)的指標(biāo)自然沒有意義。如果只是部分指標(biāo)不可用可以先用--set basic跑一遍確認(rèn)基礎(chǔ)指標(biāo)能采到再逐步擴大范圍把問題定位到具體哪類計數(shù)器權(quán)限受限。6.3 同一 kernel 多次 profiling 結(jié)果不穩(wěn)定硬件計數(shù)器一般來說是穩(wěn)定的但如果你發(fā)現(xiàn)多次結(jié)果波動明顯首先要考慮 GPU 頻率是否在動態(tài)變化。默認(rèn)情況下 GPU 存在 boost 機制頻率會在負(fù)載和溫度的影響下波動。調(diào)頻會造成 SM 吞吐、DRAM 吞吐這類指標(biāo)出現(xiàn)差異。解決方法是固定 GPU 頻率例如在 Linux 下用sudo nvidia-smi -lgc 1500,1500鎖定到一個中間頻率或者使用 ncu 自帶的時鐘控制選項。鎖定頻率會犧牲一些峰值性能但換來的是一致性這對對比測試非常關(guān)鍵。如果是多用戶共享的 GPU 節(jié)點還要確認(rèn) profiling 期間沒有其他任務(wù)在搶占顯存帶寬?？梢杂胣vidia-smi看一眼有沒有陌生的高占用進(jìn)程或者把你的測試任務(wù)放到獨占節(jié)點跑。我個人習(xí)慣是每個優(yōu)化點至少跑三次收集數(shù)據(jù)取中位數(shù)作為結(jié)論避免單次數(shù)據(jù)里的偶然抖動誤導(dǎo)判斷。6.4 指標(biāo)與直覺不符一個真實案例分享一個實際案例。之前優(yōu)化過一個流式計算內(nèi)核SOL 頁面顯示 DRAM 吞吐已經(jīng)接近 95% 峰值但是運行時間還是比我預(yù)期的高。當(dāng)時直覺認(rèn)為“都已經(jīng)頂滿帶寬了應(yīng)該沒法再快了”但仔細(xì)看 Memory Workload Analysis 后發(fā)現(xiàn)L2 命中率只有 20%全局訪問的 sector 效率只有 50% 左右。這意味著雖然 DRAM 吞吐打滿了但其中一半帶寬是在搬運無用數(shù)據(jù)因為訪存沒有合并。我調(diào)整了數(shù)據(jù)布局把輸入數(shù)組轉(zhuǎn)成結(jié)構(gòu)體數(shù)組并按向量化方式讀取后同樣的問題規(guī)模下 DRAM 吞吐從 95% 降到 70%但運行時間卻縮短了將近一半。這就是“指標(biāo)與直覺相?！北澈蟮恼嫦鄦我恢笜?biāo)只是探針要組合著看才能反映真實瓶頸。最后再分享一點個人習(xí)慣拿到一個慢 kernel我先跑一次全量 profiling重點看 SOL 柱狀圖判斷是計算側(cè)還是內(nèi)存?zhèn)热缓箜樦款i方向做局部深度分析。這套流程前前后后只花十幾分鐘但能幫我節(jié)省大量瞎調(diào)的時間。優(yōu)化完還要用同一組--metrics做回歸確保硬件指標(biāo)確實向預(yù)期方向移動了再回到正常模式下驗證真實執(zhí)行時間才算真正閉環(huán)。