📚 课程目录第4章性能分析工具

4. 性能分析工具：NVIDIA Nsight Compute、Nsight Systems、nvprof等工具的使用与性能指标解读

4.1 工具定位与核心原理

GPU内核的优化不能靠“猜”，必须依赖精确的硬件计数器与时间戳数据。NVIDIA提供了三款定位不同的性能分析工具，理解它们的差异是高效调优的第一步。

Nsight Systems（nsys）：系统级时间线分析工具，用于观察CPU与GPU之间的异步执行、内核启动间隙、内存拷贝（H2D/D2H）、CUDA API调用耗时。它回答的是“时间去哪了”的问题，适合发现负载不均衡、同步等待、小内核启动过多等宏观瓶颈。
Nsight Compute（ncu）：内核级微架构分析工具，直接读取GPU硬件性能计数器（如SM占用率、访存吞吐、指令混合、warp stall原因）。它回答的是“内核内部为什么慢”的问题，是本节课程的核心工具。
nvprof：旧版命令行分析器，在CUDA 10.2之后被标记为弃用，但在老项目或远程无GUI环境中仍可能遇到。其功能被Nsight系列取代，但部分脚本仍依赖其输出格式。

选型建议：宏观时序问题（如CPU-GPU同步不佳）优先用Nsight Systems；单个内核的指令效率、访存模式、占用率瓶颈则必须用Nsight Compute。两者配合使用，形成“先系统后内核”的分析路径。

4.2 核心指标解读方法

Nsight Compute会输出数十项指标，但调优时只需优先关注以下五类核心指标，它们构成了GPU内核性能的“体检表”。

指标类别	关键指标	健康范围参考	瓶颈信号
占用率	SM Occupancy（实际/理论）	≥50%（计算密集） ≥75%（访存密集）	寄存器溢出、共享内存超限、block过小
访存效率	Memory Throughput L1/L2 Hit Rate	DRAM吞吐接近峰值 L2命中率>60%	非合并访问、缓存抖动、访存延迟未隐藏
指令效率	Issue Slots Active Executed IPC	IPC > 3（Maxwell+）	指令依赖过长、分支发散、低效指令
Warp状态	Stall原因分布（Long Scoreboard, Wait, Barrier等）	无单一原因超过40%	访存等待/同步等待/资源竞争
计算吞吐	FMA/ALU利用率 Tensor Core利用率	FMA利用率>70%	整数/浮点混合、非向量化运算

实操命令示例：对编译好的可执行文件中的某个内核进行快速分析。

# 使用Nsight Compute分析所有内核（简略模式）
ncu --set basic ./my_kernel

# 分析指定内核，输出详细SM和访存指标
ncu --kernel-name regex:my_kernel --section MemoryWorkloadAnalysis \
    --section SchedulerStats --section WarpStateStats ./my_kernel

# 生成交互式报告（GUI）
ncu --export /tmp/profile.ncu-rep ./my_kernel

4.3 实战案例：矩阵乘法内核的瓶颈定位

假设我们有一个简单的SGEMM内核（单精度矩阵乘法），在V100上实测性能仅为理论峰值的18%。通过Nsight Compute分析，得到以下关键数据：

# ncu关键输出片段
Section: GPU Speed Of Light Throughput
DRAM Throughput:     82.4%
Compute (SM) Throughput: 12.7%

Section: Warp State Statistics
Stall Long Scoreboard:   61.3%
Stall Wait:              15.2%
Stall Not Selected:       8.1%

Section: Memory Workload Analysis
L1/TEX Hit Rate:         32.5%
L2 Hit Rate:             48.2%
Mem Busy:                85.6%
Max Bandwidth:           78.3%

解读逻辑：

DRAM吞吐82.4%而SM计算吞吐仅12.7%，说明内核是访存瓶颈而非计算瓶颈。
Stall Long Scoreboard占61.3%，意味着warp绝大多数时间在等待内存数据返回，进一步确认访存延迟未被隐藏。
L1命中率仅32.5%，说明数据复用极差——每个线程直接读取全局内存，没有利用共享内存或寄存器缓存。

优化方案：采用分块（tiling）策略，将子矩阵加载到共享内存，并应用寄存器双缓冲。修改后重新分析，DRAM吞吐降至45%，SM吞吐升至58%，整体性能提升3.2倍。

常见误区：不要只看“占用率”一个数字。本例中占用率高达87.5%，但性能依然很差——因为高占用率只是提供了隐藏延迟的可能性，如果访存模式本身是低效的（非合并、无复用），再多的warp也无法弥补带宽浪费。

4.4 方法流程：系统化分析五步法

结合Nsight工具链，推荐以下标准分析流程，避免盲目优化：

系统级扫描：运行nsys profile --stats=true ./app，查看内核耗时占比、拷贝耗时、CPU间隙。若GPU空闲率超过30%，先解决启动/同步问题。
内核级初筛：对耗时Top3内核运行ncu --set full，查看Speed of Light（SOL）吞吐图，判断是计算瓶颈还是访存瓶颈。
微架构定位：根据瓶颈类型深入对应Section——访存瓶颈看MemoryWorkloadAnalysis，计算瓶颈看ComputeWorkloadAnalysis，延迟瓶颈看WarpStateStats。
代码映射：将指标反推到源码行（ncu支持--source参数显示行级PC采样），找到具体问题代码。
修改验证：每次只改一个变量，重新profile对比SOL图和stall分布，确认指标确实改善。

效率技巧：使用ncu --launch-count 1只分析一次内核启动，减少重复运行时间。对于需要快速迭代的场景，可先用--set basic获取SOL概览，确认方向后再用--set full深挖细节。

4.5 误区与复盘

在实际项目中使用这些工具时，以下错误认知会显著降低调优效率：

误区一：直接看ncu报告中的“Occupancy”数值。该数值是理论最大值，实际有效占用率受限于寄存器分配、共享内存和调度槽。应结合WarpStateStats中的Active Warps Per Scheduler来判断真实隐藏延迟能力。
误区二：忽略Nsight Systems直接分析内核。如果内核本身只占程序总时间的20%，优化它意义有限。先确认内核确实是热点，再投入精力。
误区三：混淆“高吞吐”与“高效率”。DRAM吞吐90%可能意味着访存模式良好，但也可能意味着大量不必要的重复读取。应结合L1/L2命中率和实际计算量综合判断。
误区四：在release版本上分析。编译器优化级别（-O3）会显著影响指令调度和寄存器分配，务必在-O3且开启-lineinfo的构建上进行分析，否则结果失真。

复盘案例：某图像处理内核，ncu显示“Compute Throughput 92%”，团队误判为计算饱和，反复优化指令混合无果。后经Nsight Systems发现，该内核每帧启动1200次，每次仅处理32x32像素，启动开销占帧总时间68%。最终通过合并内核启动（kernel fusion）将启动次数降至8次，性能提升5倍。这说明工具选择错误会导致完全无效的优化方向。

正确的工具使用习惯应当是：先用Nsight Systems建立全局时间观，再用Nsight Compute深入微架构细节，最后用ncu的源码映射功能精准定位代码行。三者结合，才能让每一次代码修改都有数据支撑，避免“盲人摸象”式的调优。