课程导入：学习目标、适用人群与GPU性能分析概述

1.1 为什么需要系统化学习GPU性能分析

现代高性能计算与深度学习训练高度依赖GPU算力，但绝大多数开发者只关注“程序能否运行”，很少追问“GPU是否被高效利用”。一个典型的CUDA程序，即使逻辑完全正确，其实际吞吐量可能仅为硬件峰值的10%~30%。造成这种差距的原因包括：内存访问未合并、线程束发散、占用率不足、内核启动开销过大、访存与计算重叠不足等。这些问题无法通过代码审查直接发现，必须依赖专业的性能分析工具进行量化定位。

本课程以NVIDIA Nsight Compute（简称Ncu）为核心工具，围绕其分析报告中的关键指标与可视化视图，训练学员从“看报告”到“读报告”再到“优化程序”的完整能力。课程不追求罗列所有参数，而是聚焦于最影响性能判断的指标组合与解读逻辑。

1.2 学习目标与适用人群

适用人群包括：CUDA C/C++开发者、高性能计算工程师、深度学习框架底层算子开发人员、以及希望系统提升GPU程序性能的研究生或科研人员。学员需具备基本的CUDA编程经验（了解线程块、线程、共享内存概念），但不要求有性能分析工具使用经验。

1.3 GPU性能分析的核心原理

GPU性能分析的本质是回答三个问题：硬件资源是否被充分利用？程序是否受限于某个特定资源？瓶颈出现在哪个执行阶段？现代GPU包含大量并行执行单元（SM）、多层次缓存、全局显存与各种专用硬件单元。性能分析工具通过硬件计数器（Hardware Counters）在程序执行期间采集事件发生次数，例如：已发射指令数、内存事务数、线程束调度次数、L2缓存命中率等。

Nsight Compute采用基于采样的性能分析方式，它并非模拟程序执行，而是在真实GPU硬件上运行内核，并通过性能计数器收集数据。其核心分析模型是“瓶颈树”：从最高层的“GPU利用率”开始，逐层向下分解为“计算资源利用率”“内存资源利用率”和“延迟隐藏能力”，最终定位到具体的硬件单元或程序行为。

1.4 Nsight Compute工具简介与工作流程

Nsight Compute是NVIDIA官方提供的内核级性能分析器，它区别于Nsight Systems（系统级追踪工具）。Ncu专注于单个内核的微观行为，能够提供超过1000项硬件指标和多个分析页面。其典型使用流程如下：

1. 构建程序：使用-lineinfo编译选项生成行号信息，便于将性能数据映射到源代码行。
2. 运行分析：通过命令行或GUI对目标内核进行采样。
3. 查看报告：分析SOL、内存工作负载、调度器统计等页面。
4. 定位瓶颈：结合源码视图与指标，确定性能限制因素。
5. 修改优化：调整代码后重新分析，对比前后指标变化。

命令行基本用法示例：

# 对可执行文件中的名为"myKernel"的内核进行分析
ncu --kernel-name myKernel --launch-count 1 ./my_app

# 输出详细报告到文件
ncu --set full --export report.ncu-rep ./my_app

# 仅查看SOL概览
ncu --section SpeedOfLight ./my_app

1.5 常见误区与复盘

误区一：只关注GPU利用率百分比。很多开发者看到“GPU利用率99%”就认为程序已优化到位。实际上，该指标只表示GPU有活动，并不区分是计算活动还是内存等待活动。一个频繁访问全局内存且大量线程阻塞的内核，同样可能显示高利用率，但实际计算吞吐极低。

误区二：忽略“内存吞吐量”与“计算吞吐量”的平衡。SOL页面会分别显示计算资源利用率和内存资源利用率。如果计算利用率仅20%而内存利用率已达95%，说明程序是访存密集型，此时增加计算指令或减少内存访问才是正确方向，而不是盲目增加线程数。

误区三：混淆“理论占用率”与“实际占用率”。理论占用率由启动配置（块大小、共享内存用量）决定，而实际占用率受限于寄存器溢出、同步等待等因素。Ncu报告中的Achieved Occupancy才是真实值，两者差距过大时需检查是否有寄存器溢出或不当的__syncthreads()使用。