一、性能剖析概述：为什么我们需要它？

做CUDA开发，最怕什么？

不是写不出代码，而是写出来的代码跑得慢。更可怕的是——你不知道它为什么慢。

我刚开始接触GPU编程那会儿，写了个矩阵乘法的kernel，自我感觉良好。结果一跑，比CPU还慢。我当时就懵了。后来才知道，问题出在全局内存的访问模式上。但如果没有性能剖析工具，我可能永远都找不到这个瓶颈。

说白了，性能剖析就是给你的kernel做一次“体检”。它能告诉你：时间花在哪了？资源用满了吗？瓶颈是计算还是访存？

1.1 为什么需要性能剖析？

我总结了几点核心原因：

• 定位瓶颈：代码跑得慢，你得知道是计算单元在等数据，还是数据在等计算单元。这两者的优化方向完全不同。
• 验证优化：你改了一版代码，觉得应该快了。但快了多少？是10%还是10倍？没有数据，你就是在“盲人摸象”。
• 避免“负优化”：我曾经遇到过，为了优化共享内存，结果把全局内存的访问模式搞乱了，性能反而下降了20%。性能剖析能帮你及时止损。
• 理解硬件行为：GPU的架构很复杂。warp调度、缓存命中率、内存带宽利用率……这些指标光靠猜是猜不出来的。

1.2 性能剖析的四个维度

我个人习惯从四个维度去审视一个kernel的性能。你想想看，就像体检要查心率、血压、血常规一样，每个维度都对应着不同的健康指标。

维度	关注点	典型指标	我常问的问题
时间	整体执行耗时	Kernel执行时间、总耗时	这个kernel花了多少毫秒？
吞吐量	计算单元利用率	FLOPs、Occupancy、指令吞吐	计算单元吃饱了吗？
带宽	内存系统效率	全局内存带宽、L1/L2命中率	数据搬运速度够快吗？
延迟	指令/数据等待时间	内存延迟、同步开销	warp在等什么？

嗯，这里要注意：这四个维度是相互关联的。比如，带宽不足会导致计算单元空闲，从而降低吞吐量。你不能只看一个指标就下结论。

1.3 性能剖析工具概览

工欲善其事，必先利其器。NVIDIA给我们准备了一套很完整的工具链。我按使用场景把它们分成了两类：

1.3.1 宏观分析：Nsight Systems

这个工具我用的最多。它就像kernel的“行车记录仪”，能记录整个应用的执行时间线。

• 用途：看CPU和GPU之间的交互、内存拷贝、kernel启动顺序。
• 特点：时间粒度是微秒级的，能看到整个应用的瓶颈在哪。
• 我的经验：有一次我发现一个应用GPU利用率只有30%，用Nsight Systems一看，原来是CPU在频繁地启动小kernel，启动开销把性能吃掉了。

1.3.2 微观分析：Nsight Compute

这是kernel级别的“显微镜”。它能深入到每个指令、每个warp的行为。

• 用途：分析单个kernel的瓶颈，比如是计算受限还是访存受限。
• 特点：提供详细的性能指标，比如L1缓存命中率、bank conflict次数。
• 避坑指南：我曾经用Nsight Compute分析一个kernel，发现occupancy很高但性能很差。后来发现是共享内存的bank conflict太严重了。这个工具能帮你看到这些细节。

1.3.3 经典工具：nvprof 和 ncu

nvprof是早期的命令行工具，现在基本被ncu（Nsight Compute的命令行版本）取代了。但有些老项目还在用。

• nvprof：简单直接，适合快速看个大概。但功能有限，不推荐在新项目中使用。
• ncu：功能强大，支持脚本化分析。我习惯在自动化测试中用ncu收集性能数据。

1.4 知识体系总览

为了让你更直观地理解这一章的内容，我画了一张图。它展示了性能剖析的核心逻辑：从“为什么”到“怎么做”，再到“用什么工具”。

1.5 我的建议

如果你是新手，我建议你从Nsight Systems开始。先看整体，再深入细节。不要一上来就扎进Nsight Compute的几百个指标里，容易迷失方向。

另外，性能剖析不是一次性工作。每次修改代码后，都应该跑一遍性能数据。我习惯把每次优化的性能数据记录下来，形成一个“性能基线”。这样，即使过了几个月，我还能知道当时的优化效果。

好了，这一章就到这里。记住：没有数据，就没有优化。下一章，我们会深入Nsight Systems，看看怎么用它来定位应用的宏观瓶颈。