4、Nsight Compute界面：内核分析视图、性能指标面板、源代码关联、寄存器与内存视图
好，咱们今天来聊聊 Nsight Compute 的界面。
说实话，我第一次打开这个工具的时候，有点懵。面板太多了，信息量巨大。但别怕，我带你捋一遍。你只要抓住四个核心区域，就能快速上手。
这四个区域分别是：内核分析视图、性能指标面板、源代码关联、以及寄存器与内存视图。它们就像四个仪表盘，告诉你 GPU 到底在干嘛。
内核分析视图：一眼看穿内核瓶颈
打开 Nsight Compute，第一个映入眼帘的就是内核分析视图。说白了，这就是一个「内核体检报告」。
它会列出你程序里所有调用的 CUDA 内核。每个内核一行，关键信息一目了然：
- 内核名称：比如
matmul_kernel - 执行时间：这个内核跑了多久
- 占用率：SM 上活跃 warp 的比例
- 瓶颈类型：计算瓶颈？访存瓶颈？还是延迟瓶颈？
我个人习惯，先看执行时间最长的那个内核。别在那些只跑了几微秒的内核上浪费时间。抓住大头，优化才有意义。
核心思路：内核分析视图帮你快速定位「哪个内核最需要优化」。别一上来就钻细节，先看全局。
性能指标面板：数据会说话
选中一个内核后，右侧的性能指标面板就派上用场了。这里的数据非常丰富，我挑几个重点说说。
吞吐量指标：
- 计算吞吐量：SM 每秒执行了多少指令
- 内存吞吐量：全局内存的读写带宽
- L1/L2 缓存命中率：缓存用得好不好
指令混合：
- 整数指令、浮点指令、访存指令各占多少比例
- 如果浮点指令占比很低，说明你的计算单元在「摸鱼」
延迟分析：
- 长延迟操作（如全局内存访问）是否过多
- warp 调度效率如何
我记得有一次，我优化一个图像处理内核。看吞吐量指标，内存带宽利用率只有 30%。我当时就纳闷，明明数据量很大啊。后来发现是访问模式不对，导致缓存命中率极低。改成连续访问后，带宽利用率直接飙到 85%。
小技巧：关注「瓶颈指示器」这个字段。它会直接告诉你当前内核是 compute-bound 还是 memory-bound。这能帮你快速确定优化方向。
源代码关联：让代码和性能对上号
这个功能我特别喜欢。它把 CUDA 源代码和生成的 PTX/SASS 汇编指令关联在一起。
你想想看，你写了一段代码：
__global__ void vec_add(float *a, float *b, float *c, int n) {
int idx = blockIdx.x * blockDim.x + threadIdx.x;
if (idx < n) {
c[idx] = a[idx] + b[idx];
}
}在源代码关联视图中，每一行代码旁边都会显示对应的汇编指令数量，以及该行代码消耗的周期数。哪一行是热点，一目了然。
我曾经遇到过一个 case，一个简单的加法内核，性能死活上不去。打开源代码关联一看，发现 if (idx < n) 这个边界检查居然占了 40% 的指令周期。后来我调整了 grid 大小，让线程数刚好是 n 的倍数，避免了分支发散，性能直接翻倍。
注意：源代码关联依赖编译选项。记得在编译时加上 -lineinfo 或 -G 选项，否则看不到行号信息。我刚开始用的时候就踩过这个坑，折腾了半天才发现是编译参数没加。
寄存器与内存视图：深入底层
这个视图是给「硬核玩家」准备的。它展示了内核在寄存器、共享内存、全局内存上的使用情况。
寄存器压力：
- 每个线程用了多少寄存器
- 如果寄存器使用过多，会降低占用率
- 一般建议每个线程不超过 32 个寄存器
共享内存：
- 每个 block 用了多少共享内存
- 有没有 bank conflict
- 共享内存的访问模式是否高效
全局内存访问：
- 访问是否合并（coalesced）
- 有没有非对齐访问
- L2 缓存命中率
嗯，这里要注意。寄存器压力是个很隐蔽的问题。你写代码时可能觉得变量不多，但编译器优化后，寄存器使用量可能远超你的预期。
我有个习惯：每次写完内核，都会看一眼寄存器使用量。如果超过 32，我会尝试用 __launch_bounds__ 限制一下，或者手动减少局部变量。别小看这一步，有时候能带来 20% 的性能提升。
一句话总结：寄存器与内存视图告诉你「GPU 的每一份资源都用在了哪里」。资源用得好，性能自然好。
四个视图如何配合使用？
我一般的工作流是这样的：
- 先看内核分析视图，找到最耗时的内核
- 再看性能指标面板，判断是计算瓶颈还是访存瓶颈
- 然后打开源代码关联，定位到具体的代码行
- 最后用寄存器与内存视图，检查底层资源使用是否合理
这四个视图层层递进，从宏观到微观，帮你把性能问题彻底挖出来。
好了，界面部分就聊到这里。记住，工具只是辅助，关键还是你对 GPU 执行模型的理解。多动手，多分析，慢慢就有感觉了。