📚 课程目录第1章课程导入

课程导入：学习目标、课程大纲与Nsight Compute在性能分析中的角色

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

在CUDA程序开发中，许多开发者会遇到这样的困惑：程序能运行，但GPU利用率不高；显存占用正常，但计算吞吐远低于硬件峰值；代码已经做了“常规优化”，却仍然无法达到预期加速比。这些问题的根源往往在于——我们缺少一种可量化、可定位、可验证的性能分析方法论，而不仅仅是“凭经验改代码”。

NVIDIA Nsight Compute（简称Ncu）是当前CUDA平台上最专业的内核级性能分析器。它能够深入GPU内核（Kernel）执行细节，采集数百项硬件计数器数据，帮助开发者回答三个核心问题：

瓶颈在哪？——是访存延迟、计算吞吐、指令发射，还是线程调度问题？
为什么慢？——是缓存命中率低、bank conflict严重，还是分支发散导致执行效率下降？
改哪里最有效？——通过“瓶颈分析-优化-再验证”的闭环，让每一次代码修改都有数据支撑。

本课程不打算罗列Ncu的全部功能，而是聚焦于指标解读与瓶颈定位这两条主线，帮助你建立从“看到指标”到“定位问题”再到“指导优化”的完整思维链。

课程定位：这是一门“方法论+实战”课程。每一章都会围绕真实GPU内核案例，展示如何通过Ncu的Speed of Light、Memory Workload Analysis、Scheduler Statistics等关键分析页面，快速锁定性能瓶颈类型，并给出对应的优化方向。

1.2 课程学习目标

完成本课程后，你将能够：

熟练使用Ncu命令行与NVIDIA Nsight Compute GUI，完成内核级性能剖析，并理解各分析页面的数据含义。
准确解读核心性能指标，包括SM（Streaming Multiprocessor）吞吐率、内存带宽利用率、缓存命中率、寄存器溢出（Spill）、Warp占用率等。
建立瓶颈分类思维，能够区分计算密集型（Compute Bound）、访存密集型（Memory Bound）和延迟密集型（Latency Bound）内核，并针对不同类型采取差异化优化策略。
掌握Speed of Light（SOL）模型，通过理论峰值与实际吞吐的对比，快速判断内核距离硬件极限还有多大差距。
能够独立完成一次性能分析报告，包括瓶颈定位、根因分析、优化建议和优化前后对比。

1.3 课程大纲总览

本课程共分为六个模块、30个章节，内容层层递进：

模块	章节范围	核心内容
模块一：基础入门	第1-5章	课程导入、GPU架构与执行模型、Ncu安装与基本用法、Profile工作流程、命令行与GUI操作
模块二：核心指标解读	第6-12章	Speed of Light模型、SM吞吐指标、内存带宽与延迟、缓存与共享内存指标、Warp与调度指标、指令混合与吞吐
模块三：瓶颈定位方法	第13-18章	瓶颈分类框架、访存瓶颈定位、计算瓶颈定位、延迟隐藏分析、Occupancy与寄存器优化、多瓶颈综合判断
模块四：实战案例	第19-24章	矩阵乘法优化、归约（Reduction）内核、卷积（Convolution）算子、Stencil计算、稀疏矩阵处理、自定义算子剖析
模块五：高级专题	第25-28章	多GPU与MIG分析、CUDA Graphs性能分析、与Nsight Systems联合分析、性能回归测试
模块六：总结与展望	第29-30章	性能分析报告模板、常见误区复盘与优化决策树

1.4 Nsight Compute在性能分析中的角色定位

在GPU性能分析工具链中，不同工具承担不同职责。Ncu专注于内核级（Kernel-level）微观分析，而NVIDIA Nsight Systems（Nsys）则负责应用级（Application-level）宏观分析。两者互补，构成完整的性能分析体系。

下图展示了Nsight Compute在整个性能分析流程中的核心位置：

从上图可以看出，Ncu在性能分析流程中处于“内核微观剖析”的核心位置。当Nsight Systems发现某个内核耗时异常时，下一步就需要使用Ncu深入该内核，采集SM内部执行数据，定位具体瓶颈。

1.5 核心原理：Ncu如何“看到”GPU内部状态

Ncu的工作原理基于硬件性能计数器（Hardware Performance Counters）。GPU的每个SM内部都集成了一组可编程计数器，能够记录诸如：指令发射数量、L1/L2缓存命中率、全局内存读写事务数、共享内存bank冲突次数、Warp调度等待周期等底层事件。

Ncu通过以下三步完成分析：

配置阶段：用户指定需要采集的指标集合（如SpeedOfLight、MemoryWorkloadAnalysis等），Ncu将这些指标映射到对应的硬件计数器。
执行阶段：目标内核在GPU上运行时，Ncu通过驱动层接口读取计数器值。由于硬件计数器数量有限，Ncu可能将一次分析拆分为多次Pass（重复运行内核）来采集全部指标。
归因阶段：Ncu将计数器原始值换算为可读指标（如吞吐率百分比、带宽利用率），并关联到具体的源代码行或PTX指令，生成分析报告。

重要概念——Pass：由于GPU硬件计数器资源有限，Ncu在一次Profile中可能需要多次运行同一内核（每次运行称为一个Pass），每次采集不同的计数器子集。因此，分析耗时 = 内核运行时间 × Pass数量。在后续章节中，我们会介绍如何通过--set参数控制采集范围，减少Pass数量以提升分析效率。

1.6 典型工作流程：从宏观到微观

在实际项目中，推荐采用以下分层分析流程：

# 第一步：宏观定位（Nsight Systems）
nsys profile --stats=true -o app_profile ./my_app

# 第二步：微观剖析（Nsight Compute）
# 先使用默认set快速查看SOL概览
ncu --set default -o kernel_profile ./my_app

# 第三步：针对可疑内核深入分析
ncu --kernel-name regex --set full --launch-count 1 ./my_app

# 第四步：导出并生成报告
ncu --import kernel_profile.ncu-rep --page details

该流程的核心思想是：先用Nsight Systems找到“哪个内核慢”，再用Ncu分析“为什么慢”。避免直接对所有内核进行全量Ncu分析，因为那会耗费大量时间。

1.7 常见误区与复盘

误区一：只关注SM占用率（Occupancy）。许多开发者认为提高Occupancy就一定能提升性能。实际上，Occupancy只是“隐藏延迟的能力”，如果内核本身是Memory Bound且访存模式极差，再高的Occupancy也无法提升带宽利用率。正确做法是先判断瓶颈类型，再决定是否调整Occupancy。

误区二：忽略“分析本身的开销”。Ncu的计数器采集会引入额外开销，尤其是使用--set full时，内核可能被重复运行数十次。对于本身运行时间极短（<5微秒）的内核，Ncu的测量误差会显著增大。此时应使用--launch-count多次运行取平均值，或考虑使用--kernel-name过滤特定内核。

误区三：盲目追求“某个指标达到100%”。SOL图中的Compute（SM）吞吐和Memory吞吐不可能同时达到100%。如果两者都只有50%，说明可能存在“延迟瓶颈”或“调度瓶颈”，而不是单纯的计算或访存问题。需要结合Scheduler Statistics页面进一步分析Warp Stall原因。

1.8 本节小结

本章作为课程导入，明确了三个关键认知：

学习目标：掌握Ncu指标解读与瓶颈定位方法，能够独立完成内核性能分析报告。
工具定位：Ncu是内核级微观分析工具，与Nsight Systems形成互补，是性能优化闭环中不可或缺的一环。
核心思维：性能分析不是“看数字”，而是“找瓶颈-归因-优化-验证”的循环过程。后续所有章节都将围绕这一循环展开。