使用 Nsight Compute 进行 kernel 性能分析

测试用例：github – cuda_perf

• 编译时，加上 -lineinfo 参数，Nsight Compute 分析时，可以看到具体的 C++/cu 代码。
• 另外一篇性能分析文章：CUDA 架构(1.1)：Hopper架构及性能分析(ncu) + 性能优化。

1. 启动配置

使用Nsight Compute运行被测试CUDA程序，启动时，指定metrics为full：

1.1. 命令行方式

# 完整分析，输出到文件
ncu --set full -o gemm_sm80_profile ./ncu_gemm_sm80 4096 4096 4096

# 查看 memory 相关指标
ncu --set memory ./ncu_gemm_sm80 4096 4096 4096

# 查看 compute 相关指标
ncu --set compute ./ncu_gemm_sm80 4096 4096 4096

# 查看 roofline
# 1. Memory Throughput(GB/s)、L2 Cache Throughput(GB/s)、Compute (SM) Throughput(TFLOPS/s)
# 结果以百分比形式给出，即与理论峰值的比值
# 2. SM Active Cycles / Elapsed Cycles，他们的比值表示 SM 的利用率，即可以看出等待内存的时间占比
ncu --set roofline ./ncu_gemm_sm80 4096 4096 4096

# 查看 occupancy 相关指标
ncu --section Occupancy ./cu_gemm_sm80.exe 4096 4096 4096

# 查看 shared memory bank conflict
ncu --metrics l1tex__data_bank_conflicts_pipe_lsu_mem_shared,l1tex__data_bank_conflicts_pipe_lsu_mem_shared_op_ld.sum ./ncu_gemm_sm80 4096 4096 4096

2. 分析Bank Conflicts

被测试CUDA程序运行结束后，打开Nsight Compute的结果页面（Details），进入Memory Workload Analysis章节，在章节标题右侧，选择Memory Tables，查看Shared Memory部分：

Details页面里显示的Shared Memory的Bank Conflicts信息，由于其测量数据来源于硬件计数器，还可能包括仲裁冲突(arbitration conflicts)：

• LDGSTS的Fill Return（全局/共享内存加载的返回数据）
• TMA的Fill Return（Tensor Memory Accelerator的返回数据）
• Tensor Core对共享内存的读取

使用Source页面的L1 Wavefonts Shared Excessive结果，应该更准确：

两个页面分析结果为什么会有差异？

如何识别可优化的Bank Conflict：

• 使用源页面（Source View）的Excessive计数器
• 这些是由地址发散和真实的Bank Conflict引起的
• 这些可以通过代码优化来消除

哪些冲突无法修复：

• 详情页面中显示的仲裁冲突无法通过代码优化解决
• 这些是系统级别的问题（Tensor Core、TMA、全局内存的更高优先级访问）
• 这些是硬件行为的自然结果

A. 参考资料

• Questions on L1 Bank Conflict statistic discrepancies between Details and Source pages
• Shared memory bank conflicts and nsight metric
• Requests, Wavefronts, Sectors Metrics: Understanding and Optimizing Memory-Bound Kernels with Nsight Compute。视频资料。
• NVIDIA Kernel级性能分析工具Nsight Compute入门详解：详细讲解 Nsight Compute 中各个页面中的参数。