4. Nsight Compute深入：内核分析器使用、Occupancy与Warp分析、Memory与Compute吞吐

好，咱们今天聊点硬核的。Nsight Compute，这玩意儿我用了快十年了。说实话，刚接触CUDA那会儿，我总觉得优化就是改改循环、调调线程块大小。直到有一次，一个内核跑得比CPU还慢，我才老老实实打开Nsight Compute，一看——哦，原来瓶颈在这儿。

这一章，我会带你深入内核分析器。咱们不讲那些花里胡哨的界面操作，直接聊怎么用它定位问题、怎么读懂Occupancy、怎么分析Warp调度、怎么算Memory和Compute的吞吐。嗯，都是实战经验。

4.1 内核分析器：你的第一把手术刀

Nsight Compute的核心，说白了就是帮你回答三个问题：

  • 我的内核在等什么？
  • 计算单元吃饱了吗？
  • 显存带宽用满了吗？

我个人习惯，拿到一个待优化的内核，第一步不是看代码，而是跑一次Profile。你想想看，代码写得再漂亮，硬件不买账也是白搭。

关键指标速查表

指标含义理想值
Occupancy活跃Warp占最大Warp数的比例≥ 50%
Warp Execution Efficiency每个Warp中活跃线程的比例≥ 90%
Memory Throughput显存带宽利用率≥ 80%
Compute Throughput计算单元利用率≥ 70%

你可能会问：这些指标怎么读？别急，咱们一个一个拆。

4.2 Occupancy：别被数字骗了

Occupancy，直译就是“占用率”。很多新手一上来就追求100% Occupancy，觉得越高越好。我在项目中遇到过这种情况：一个内核Occupancy 100%，但性能反而比60%的时候还差。为什么会这样？

因为Occupancy高，不代表你的Warp都在干活。它只说明SM里塞满了线程块，但线程块里的线程可能都在等内存。说白了，Occupancy是“容量指标”，不是“效率指标”。

我的经验法则：

  • 计算密集型内核：Occupancy 50%~75% 就够了，太高反而会挤占寄存器
  • 访存密集型内核：Occupancy 尽量高，用来隐藏延迟
  • 如果Occupancy低，先看寄存器用量和共享内存用量

Nsight Compute里有个好用的功能叫“Occupancy Analysis”。它会告诉你当前内核的瓶颈是寄存器还是共享内存。我曾经优化过一个内核，Occupancy只有25%，一看——每个线程用了128个寄存器。我把它降到64，Occupancy直接翻倍，性能提升了40%。

4.3 Warp分析：线程到底在干嘛？

Warp是GPU执行的基本单位。一个Warp里32个线程，如果它们走的分支不一样，那就糟了——这叫“Warp Divergence”。

我记得有一次，一个同事跑过来问我：“为什么我的内核性能这么差？”我打开Nsight Compute一看，Warp Execution Efficiency只有30%。什么意思？每个Warp里只有不到10个线程在干活，其他都在等。原因很简单：他写了个switch-case，每个线程走不同分支。

避坑指南：

我曾经在一个图像处理项目里，用if-else判断像素类型。结果Warp里32个线程，每个像素类型都不一样——32路分支，性能直接崩了。后来改成先按类型分组，再统一处理，效率提升了3倍。

Nsight Compute的Warp分析面板会告诉你：

  • 每个Warp的活跃线程数
  • 分支发散的程度
  • Warp停顿的原因（等待内存？等待计算？）

你想想看，如果Warp停顿是因为等待内存，那加计算单元也没用。如果是因为计算太密集，那就要考虑减少指令数或者用更快的指令。

4.4 Memory吞吐：带宽是命根子

GPU的显存带宽，说白了就是GPU和显存之间的“水管”。水管越粗，数据流动越快。但很多时候，我们写的代码让这根水管只用了10%。

Nsight Compute的Memory Workload分析会告诉你：

  • 全局内存访问的吞吐量
  • L1/L2缓存的命中率
  • 内存访问的合并程度

我个人最关注的是“Memory Throughput”和“Sector Utilization”。Sector Utilization低，说明你的内存访问没有合并。举个例子：

// 坏的访问模式：不合并
for (int i = 0; i < N; i++) {
    float val = data[threadIdx.x + i * blockDim.x];  // 跨步访问
}

// 好的访问模式：合并
for (int i = 0; i < N; i++) {
    float val = data[threadIdx.x + i * blockDim.x];  // 连续访问
}

嗯，这里要注意：同样的代码，不同的数据布局，性能可能差10倍。我在做矩阵转置的时候深有体会——行主序和列主序，一个天上一个地下。

4.5 Compute吞吐：计算单元吃饱了吗？

Compute吞吐，看的是SM里的计算单元（CUDA Core、Tensor Core）有没有满负荷运转。Nsight Compute会给出“Compute Utilization”和“Arithmetic Intensity”。

Arithmetic Intensity（计算强度）是个关键指标。它等于“计算量 / 访存量”。如果这个值很低，说明你的内核是访存密集型，加计算单元没用。如果很高，说明是计算密集型，可以考虑用更快的指令或者Tensor Core。

实战案例：

我在优化一个卷积层时，发现Compute Utilization只有20%，但Memory Throughput已经接近100%。一看Arithmetic Intensity——0.5，典型的访存瓶颈。后来我用了Fused Convolution，把多个操作合并成一个kernel，减少了中间结果的读写，性能提升了2倍。

Nsight Compute的“Speed of Light”图特别好用。它会画一条理论极限线，然后标出你的内核在哪个位置。如果离极限线很远，说明还有优化空间。

4.6 综合实战：一个完整的分析流程

好，咱们来走一遍完整的流程。假设你有一个内核，性能不达标：

  1. 第一步：跑Profile。打开Nsight Compute，选择你的内核，点“Profile”。等几秒钟，看结果。
  2. 第二步：看Occupancy。如果低于50%，检查寄存器用量和共享内存。我一般先看寄存器，因为这是最常见的坑。
  3. 第三步：看Warp分析。如果Warp Execution Efficiency低于80%，找分支发散。用“Source View”看哪行代码导致发散。
  4. 第四步：看Memory。如果Memory Throughput低于60%，检查内存访问模式。用“Memory Workload”看Sector Utilization。
  5. 第五步：看Compute。如果Compute Utilization低但Memory高，说明是访存瓶颈。反过来，如果Compute高但Memory低，说明是计算瓶颈。
  6. 第六步：改代码。根据瓶颈类型，选择优化策略。访存瓶颈：合并访问、使用共享内存、减少全局访问。计算瓶颈：减少指令数、使用更快的指令、用Tensor Core。

小技巧：

Nsight Compute的“Auto Analysis”功能会给你一个优化建议列表。虽然不一定全对，但作为起点很有用。我经常用它来快速定位问题，然后再手动深入分析。

4.7 知识体系总览

下面这张图，是我自己总结的Nsight Compute分析框架。你照着这个思路走，基本不会漏掉关键点。

Nsight Compute 内核分析框架 内核性能分析 Occupancy Warp 分析 Memory 吞吐 Compute 吞吐 寄存器用量 共享内存 分支发散 Warp停顿 合并访问 缓存命中率 计算强度 指令效率 优化目标：找到瓶颈 → 针对性优化 → 验证效果

这张图的核心逻辑很简单：从Occupancy、Warp、Memory、Compute四个维度切入，找到瓶颈，然后针对性优化。我每次做性能分析，都会在脑子里过一遍这个框架。

4.8 写在最后

Nsight Compute是个强大的工具，但它不会替你思考。你得学会读懂它给你的数据，然后结合自己的代码，找到真正的瓶颈。嗯，这需要练习。我刚开始用的时候，也经常被一堆指标搞晕。但慢慢你会发现，那些数字背后，其实就藏着一个简单的问题：我的GPU到底在等什么？

找到答案，优化就成功了一半。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →