使用Nsight Compute分析Bank Conflict

测试用例：github – cuda_perf

1. 启动配置

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

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结果，应该更准确：

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

指标	数据来源	测量内容	用途
Details Page	硬件计数器	Bank Conflict + 仲裁冲突	实际性能影响
Source Page	代码分析	纯粹的 Bank Conflict	代码优化

如何识别可优化的Bank Conflict：

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

哪些冲突无法修复：

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

3. 参考资料

• Questions on L1 Bank Conflict statistic discrepancies between Details and Source pages
• Shared memory bank conflicts and nsight metric