课程导入：学习目标、课程结构、Nsight Compute在GPU性能分析中的角色
1.1 为什么需要系统化学习Nsight Compute
GPU性能分析长期存在一个尴尬的困境：开发者知道程序运行慢，却难以定位瓶颈究竟在何处。传统做法是凭经验猜测——可能是核函数启动开销太大？可能是全局内存访问未合并？可能是线程束发散严重？这些猜测往往缺乏数据支撑，导致优化工作事倍功半。NVIDIA Nsight Compute（简称Ncu）作为官方性能分析工具，能够深入GPU硬件内部，以硬件计数器为基础，精确量化每个核函数的执行行为，将“猜测”转化为“测量”。
然而，Ncu的功能极其丰富，命令行参数超过百项，生成的报告包含数千个指标。初学者面对满屏的术语——SM占用率、Achieved Occupancy、Memory Throughput、Warp Stall Reasons——往往不知所措。本课程的目标，正是帮助你建立一条从“工具操作”到“指标解读”再到“优化决策”的完整链路，让你真正读懂Ncu报告，并据此做出有效的代码修改。
1.2 课程学习目标
完成本课程后，你将具备以下能力：
- 熟练操作：掌握Ncu的两种主要使用方式——命令行
ncu与交互式界面ncu-ui，能够针对不同场景选择合适的分析模式（快速分析、全量分析、内存分析、调度分析等）。 - 指标解读：理解核心硬件计数器组（SpeedOfLight、MemoryWorkloadAnalysis、SchedulerStats、WarpStateStats等）的含义，能够从报告中快速识别性能瓶颈类型——是计算受限、访存受限还是延迟受限。
- 瓶颈定位：学会使用Source Counters和指令级分析，将性能问题精确关联到具体的代码行或PTX指令，而非停留在核函数整体层面。
- 优化决策：基于Ncu数据制定优化策略，例如调整Block Size、优化内存访问模式、减少Bank Conflict、提高指令级并行度等，并能够用Ncu验证优化效果。
- 工作流整合：将Ncu集成到日常开发流程中，建立“基线测量→优化→回归测试”的可持续性能调优循环。
1.3 课程结构总览
本课程共30章，按照“基础→进阶→专题→实战”四个阶段递进组织。前5章为工具基础，第6至15章为指标深度解读，第16至22章为专项分析技术，第23至30章为综合案例复盘。下表展示了各阶段的核心主题：
| 阶段 | 章节范围 | 核心内容 | 能力目标 |
|---|---|---|---|
| 基础入门 | 第1-5章 | 工具安装、命令行操作、报告结构、Section配置、基线分析流程 | 能独立运行Ncu并生成完整报告 |
| 指标精讲 | 第6-15章 | SpeedOfLight、占用率、内存工作负载、调度器统计、Warp状态、指令混合等 | 能解读各Section指标并判断瓶颈类型 |
| 专项技术 | 第16-22章 | 内存合并分析、Bank Conflict检测、分支发散量化、核函数启动开销、多GPU分析 | 能针对特定问题选择正确的分析Section |
| 实战复盘 | 第23-30章 | 矩阵乘法、归约、卷积、Stencil、稀疏计算、Nbody等案例全流程调优 | 能独立完成从分析到优化的完整闭环 |
每章遵循统一的教学模式：先提出一个真实的性能问题，再演示如何用Ncu定位根因，接着实施优化并展示数据变化，最后总结方法论与常见误区。这种设计确保你学到的不是孤立的工具技巧，而是可迁移的性能分析方法论。
1.4 Nsight Compute在GPU性能分析中的角色定位
要理解Ncu的价值，需要先厘清它与NVIDIA其他开发工具的分工。GPU开发者常用的工具有四种：nvidia-smi用于系统级监控，Nsight Systems用于时间线级性能分析，Nsight Compute用于核函数级深度分析，CUDA-GDB用于调试。它们处于不同的抽象层级：
- nvidia-smi：只看GPU利用率、显存占用、温度等系统状态，无法感知具体核函数的执行效率。
- Nsight Systems：展示CPU与GPU的时间线，能发现核函数之间的间隙、内存拷贝与计算是否重叠，但无法回答“某个核函数内部为什么慢”。
- Nsight Compute：深入到单个核函数内部，利用硬件性能计数器（Performance Counter）测量SM内部每个流水线单元的活动情况，是唯一能揭示核函数内部瓶颈的工具。
- CUDA-GDB：用于逻辑错误排查，不涉及性能分析。
下图展示了Ncu在整个性能分析工作流中的位置——它承接Nsight Systems发现的“可疑核函数”，向下输出硬件级瓶颈证据，为代码修改提供依据：
上图揭示了Ncu的独特价值：当Nsight Systems显示某个核函数占用大量时间时，Ncu负责深入该核函数内部，量化SM各执行单元的实际利用率。例如，Nsight Systems可能告诉你matmul_kernel耗时12ms，但无法告诉你这12ms中，SM的浮点运算单元（FP32）利用率仅为15%，而访存单元（LSU）已接近饱和。这个结论只能由Ncu的SpeedOfLight Section给出。
1.5 Ncu的核心分析模型：瓶颈树
Ncu的分析逻辑基于一个核心模型——瓶颈树（Bottleneck Tree）。该模型将核函数性能问题逐层分解：第一层判断是“计算受限”还是“访存受限”还是“延迟受限”；第二层进一步细分，例如访存受限时，是全局内存带宽饱和，还是L2缓存命中率过低，还是共享内存Bank Conflict严重。每一层都有对应的Section和指标支撑。
理解这个模型至关重要，因为它决定了你使用Ncu的方式。初学者常犯的错误是打开所有Section，面对数百个指标不知所措。正确做法是：先看SpeedOfLight Section判断顶层瓶颈，再根据瓶颈类型选择性地展开下一层Section。本课程后续章节将反复训练这种“分层诊断”思维。
1.6 常见误区与学习建议
在开始工具操作之前，先澄清几个常见误区，避免你走弯路：
- 误区一：指标越多越好。实际上，Ncu每次运行采集的计数器数量有限，开启过多Section会显著增加运行时间（可能从秒级变为分钟级），且报告冗长难以聚焦。建议默认只开启
SpeedOfLight、Occupancy、WarpStateStats三个核心Section，待定位方向后再补充其他Section。 - 误区二：只看占用率。高占用率（Occupancy）并不等于高性能。当核函数为访存受限时，即使占用率达到100%，性能也不会提升。Ncu的价值在于告诉你“当前瓶颈是什么”，而非机械地追求某个指标最大化。
- 误区三：忽略Profile开销。Ncu基于硬件计数器工作，但某些计数器需要多次pass才能采集完整，导致实际执行时间被放大。对于短核函数（<5μs），建议使用
--launch-count参数多次启动以获取稳定数据。 - 误区四：直接修改代码而不做基线测量。没有基线的优化是盲目的。每次修改前，务必用Ncu保存当前版本的完整报告作为基线，修改后对比指标变化，确保优化方向正确。