一、CUDA性能剖析概述

各位同学好，我是老张。今天咱们聊聊CUDA性能剖析这件事。说实话，我见过太多人写完CUDA代码就跑，觉得能跑通就万事大吉。结果呢？性能惨不忍睹。

你想想看，GPU有几千个核心，你只用了十几个，那跟用CPU跑有啥区别？所以，性能剖析不是锦上添花，而是必修课。

我刚开始做CUDA开发时，也踩过不少坑。有一次写了个矩阵乘法，自我感觉良好。结果一测，比CPU还慢。我当时就懵了——GPU不是号称并行计算神器吗？

后来用性能剖析工具一看，好家伙，全局内存访问全是非合并的，线程束发散得一塌糊涂。说白了，代码写得再漂亮，硬件不买账也是白搭。

性能剖析能帮你回答三个核心问题：

核心观点： 没有剖析，优化就是盲人摸象。我见过有人花两周优化一个根本不存在的瓶颈，结果真正的问题纹丝不动。

CUDA生态里，性能剖析工具主要分两类。我个人习惯两种都备着，看场景切换。

类型	代表工具	适用场景	我的使用频率
命令行	nvprof、nsys、ncu	自动化测试、CI集成、远程服务器	70%
图形化	Nsight Systems、Nsight Compute	深度分析、可视化、教学演示	30%

命令行工具，说白了就是快。我在服务器上调试时，ssh连上去，一行命令就能拿到性能数据。比如：

nvprof --metrics gld_efficiency ./my_kernel

这条命令能告诉你全局内存加载效率。如果低于80%，嗯，你的内存访问模式大概率有问题。

图形化工具呢，适合做"体检"。Nsight Systems能展示整个应用的timeline，哪个kernel在跑，数据在CPU和GPU之间怎么搬的，一目了然。我遇到性能问题时，经常先开Nsight Systems扫一眼，心里就有数了。

我的建议： 新手先从图形化工具入手，直观。等熟练了，再玩命令行。别一上来就背参数，容易劝退。

这三个指标，是性能剖析的"三驾马车"。我面试新人时，必问这三个概念。为什么？因为它们直接决定了你的kernel能跑多快。

说白了就是"单位时间能干多少活"。对于GPU来说，通常指每秒能处理多少浮点运算（FLOPS），或者每秒能读写多少字节（带宽）。

我记得有一次优化一个图像处理kernel，吞吐量从50 GFLOPS提升到200 GFLOPS。你猜怎么着？只是改了一下数据布局，让内存访问更连续了。这就是剖析的价值——找到那个"一改就灵"的点。

延迟是"干一件事要等多久"。GPU里最典型的延迟就是内存访问延迟。全局内存访问一次可能要几百个周期，而寄存器几乎是零延迟。

怎么隐藏延迟？靠的是线程切换。GPU有大量线程，当一个线程在等数据时，硬件会切换到另一个线程执行。这就是为什么占用率（occupancy）那么重要。

占用率 = 实际活跃的线程数 / 硬件能支持的最大线程数。比如一个SM最多能放2048个线程，你只放了1024个，那占用率就是50%。

占用率低，意味着延迟隐藏能力差。线程在等数据时，没有足够的"替补"线程来干活，GPU就闲着。

注意： 占用率不是越高越好。我见过有人为了堆占用率，把共享内存用光了，结果每个线程能用的寄存器太少，反而导致性能下降。嗯，这里要权衡。

下面这张图，是我自己总结的CUDA性能剖析知识框架。每次做优化前，我都会对照着看一遍，确保没有遗漏。

个人经验： 刚开始学性能剖析时，别贪多。先把占用率搞明白，再去看吞吐量和延迟。这三个指标是联动的——你调了占用率，吞吐量可能就变了。我曾经花了一周调一个kernel，最后发现是占用率太低导致延迟隐藏失败，吞吐量上不去。

好了，这一章的内容就这些。记住一句话：没有度量，就没有优化。下一章咱们会深入命令行工具，手把手教你用nvprof和nsys抓性能数据。