课程导入：学习目标、课程大纲与Nsight Compute的定位
欢迎进入《Nsight Compute架构与工作流初探》的第一章。在开始接触任何工具之前，我们首先需要回答三个根本性问题：这门课要带你走到哪里？沿途会经过哪些站点？以及Nsight Compute在整个GPU性能分析版图中究竟扮演什么角色？本章将围绕这三个问题展开，为你建立一张清晰的学习地图和工具认知框架。
1.1 学习目标：从“能跑”到“跑得快”的认知跃迁
很多开发者对GPU优化的理解停留在“把循环并行化”或“用对cuBLAS函数”的层面。但当你面对一个实际的高性能计算或AI训练任务时，瓶颈往往隐藏在内存带宽、线程调度、指令流水线或缓存命中率等微观层面。本课程的学习目标不是教你背诵API，而是帮助你建立一套基于硬件计数器与性能树的可量化分析思维。
完成本课程后，你应该具备以下四项核心能力：
- 能读懂Nsight Compute的Profile报告：区分GPU Speed of Light、Memory Workload Analysis、Scheduler Statistics等关键页面，并理解每个指标对应的硬件行为。
- 能定位性能瓶颈的层级归属：判断问题是出在内存层级（global/local/shared）、执行单元（ALU/FP32/Tensor Core）、还是线程调度（warp occupancy/divergence）层面。
- 能基于数据提出优化假设：例如，当L1 Cache命中率低于30%时，你会想到调整访问模式或使用__ldg()；当Stall Long Scoreboard过高时，你会考虑增加并行度或减少依赖。
- 能验证优化前后的效果差异：利用Nsight Compute的Baseline与Diff功能，量化每一次代码改动带来的吞吐率或延迟变化。
1.2 课程大纲：六大模块递进式学习路径
本课程共30章，划分为六个逻辑模块，每个模块解决一个层次的问题。下表展示了整体结构及各模块的核心关注点：
| 模块 | 章节范围 | 核心主题 | 关键产出 |
|---|---|---|---|
| 基础入门 | 第1-5章 | 工具安装、Profile流程、界面导航 | 能独立生成并打开一份完整的Profile报告 |
| 硬件映射 | 第6-10章 | SM架构、内存层级、warp调度器 | 能将代码映射到硬件执行模型 |
| 指标精读 | 第11-16章 | Speed of Light、Memory Chart、Occupancy | 能解读关键图表并定位瓶颈 |
| 优化策略 | 第17-22章 | 访存优化、指令优化、并行度调优 | 能针对瓶颈提出具体修改方案 |
| 进阶专题 | 第23-27章 | Tensor Core分析、多GPU Profile、CUDA Graphs | 能分析现代AI工作负载 |
| 综合实战 | 第28-30章 | 真实案例复盘、性能回归测试 | 能独立完成一个完整优化项目 |
这种设计遵循“先见森林，再见树木”的原则。前5章让你快速跑通工具流程，建立整体印象；第6-10章深入硬件底层，为后续指标解读打下基础；第11章之后进入真正的瓶颈分析实战。每一章都配有可运行的示例代码和对应的Profile截图，方便你对照学习。
1.3 Nsight Compute在GPU性能分析中的角色
在NVIDIA提供的性能工具链中，Nsight Compute（简称ncu）并非孤立存在。要理解它的独特价值，我们需要先看清整个工具生态的分工。下图展示了NVIDIA主流性能工具在“开发-分析-调优”循环中的位置：
从上图可以看出，Nsight Compute处于“内核级微观分析”的生态位。它与相邻工具的核心区别可以概括为：
- Nsight Systems回答“时间都去哪了”——它展示CPU与GPU之间的时间线、API调用开销、内存拷贝耗时，帮助你定位哪个内核或哪个阶段最耗时。
- Nsight Compute回答“内核内部为什么慢”——它深入单个kernel，通过硬件计数器精确测量SM内部每个流水线阶段的利用率、内存指令的每个字节去向、warp调度器的每个时钟周期行为。
- 传统Profiler（如nvprof）虽然也能提供计数器，但缺乏Nsight Compute的相关性分析（自动将指标与源码行关联）和瓶颈树推理（自动判断瓶颈类型）。
matmul_kernel的CUDA内核上。此时你自然要问：这个内核为什么这么慢？是计算指令太多？还是内存等待太久？这时启动Nsight Compute对matmul_kernel进行Profile，它会告诉你：该内核的DRAM吞吐率仅为峰值的35%，而SM计算吞吐率达到92%。结论一目了然——这是一个内存带宽受限的内核，优化方向应该是减少全局内存访问或提高数据复用，而不是减少计算指令。
1.4 常见误区与工具选择复盘
在课程正式开始前，有必要澄清几个初学者容易混淆的认知误区，这些误区会直接影响你后续使用工具的效率：
| 误区描述 | 实际正确认知 | 后果 |
|---|---|---|
| “Nsight Compute能替代Nsight Systems” | 两者粒度不同，ncu无法看到CPU-GPU间的异步行为 | 在错误层面分析，浪费数小时找不到系统级瓶颈 |
| “Profile结果就是最终性能” | Profile本身会引入额外开销（通常5%-20%），且受时钟频率影响 | 过度优化Profile中的指标，但实际运行性能反而下降 |
| “只要Occupancy高就代表性能好” | 高Occupancy只是必要条件，还需配合高发射效率和低Stall | 盲目增加block数，导致缓存抖动加剧 |
| “所有计数器都要看一遍” | 应根据瓶颈假设选择指标组，ncu支持自定义Metric集合 | 信息过载，无法聚焦关键矛盾 |
针对上述误区，本课程在后续章节中会反复强调“假设驱动分析”的方法论。每次Profile前，先基于代码结构提出至少一个性能假设（例如“我认为共享内存bank conflict是瓶颈”），然后选择对应的计数器组去验证或推翻这个假设。这种工作方式远比盲目收集所有数据再试图解读要高效得多。
最后，让我们用一个具体的认知框架来收束本章。当你面对任何GPU性能问题时，可以按照以下三层递进逻辑来思考：
- 系统层：先确认瓶颈是否在CPU-GPU数据传输、内核启动频率或GPU利用率不足——这一层用Nsight Systems。
- 内核层：确认瓶颈在某个具体kernel内部后，用Nsight Compute分析其计算/访存/调度特征。
- 指令层：如果内核层显示计算吞吐率低，进一步用SASS分析（ncu的Source Counters页）查看具体是哪条指令拖慢了流水线。