CUDA 编译管线深入：nvcc → PTX → SASS 的优化空间

实验目标

"为什么同一份 CUDA 代码在不同架构卡上性能差异巨大？""-arch 和 -code 到底怎么填？""优化是应该在源码层做，还是在内核汇编层看？"——这些问题都指向一条被很多人跳过的链路：CUDA 编译管线。

• 理解 nvcc 的各级产物（C++ 源码 → PTX → SASS/cubin）与何时生成哪种；
• 掌握 -arch/-code/-gencode 的正确用法，避免"代码能跑但没吃到新卡特性"；
• 学会用 cuobjdump/nvdisasm 检查实际生成的 SASS，建立从源码到机器码的优化判断能力。

本篇为编译管线解析路线，命令与输出分析为通用实践，不编造具体性能基准。

第一站：理解 nvcc 的两段式编译

CUDA 编译是两段式的，与普通 C++ 编译有本质区别：

kernel.cu
   │  nvcc（host 编译器 + device 编译器协作）
   ▼
PTX（并行线程执行 ISA，架构无关的中间表示）
   │  ptxas（NVCC 内部或独立调用）
   ▼
SASS（架构相关的机器码，如 sm_80/sm_90 指令集）
   │  cubin 或嵌入 host 可执行文件
   ▼
运行期：CUDA 驱动对 PTX 可做 JIT，或直接加载 SASS

关键认知：

• PTX 是"可移植"的：一份 PTX 理论上可 JIT 到更新的架构（forward-compatible），代价是 JIT 开销与未充分优化；
• SASS 是"锁定"的：只针对编译时的 -arch 目标，换架构必须重新编译；
• host 端（nvcc 驱动部分）与 device 端（内核）是分开编译的：-arch 影响 device 端，host 端优化由 gcc/clang 负责。

第二站：-arch / -code / -gencode 的正确姿势

这是最常见的错误区。三个参数语义：

参数	含义	示例
-arch=sm_XX	指定 PTX 目标架构（虚拟架构）	-arch=sm_90
-code=sm_XX	指定 SASS 目标架构（真实架构）	-code=sm_90
-gencode arch=...,code=...	多架构组合打包（可重复多次）	-gencode arch=compute_90,code=sm_90

实践规则：

# 常见错误：只写 -arch=sm_90，且把 arch 写成真实架构名
nvcc -arch=sm_90 kernel.cu          # arch 应使用 compute_XX 或 sm_XX（语义：生成该架构 SASS）

# 正确做法 1：针对单一部署架构，最大化优化
nvcc -gencode arch=compute_90,code=sm_90 kernel.cu

# 正确做法 2：多架构兼容包（fatbin），兼顾新老卡
nvcc -gencode arch=compute_80,code=sm_80 \
     -gencode arch=compute_90,code=sm_90 \
     kernel.cu

# 正确做法 3：带上 PTX（code=compute_XX），留 forward-compat 余地
nvcc -gencode arch=compute_90,code=sm_90 \
     -gencode arch=compute_90,code=compute_90 \
     kernel.cu

工程观察：混布集群（07 章场景）里，"代码能跑"掩盖了很多问题——如果 fatbin 里只有 sm_90 的 SASS，作业被调度到 A100（sm_80）节点时要么 JIT（有 PTX）要么直接失败（无 PTX 且无对应 SASS）。部署哪个架构、打包哪些 gencode，应该与集群的卡型清单（01 章选型）对齐，而不是沿用默认。

第三站：检查实际产物——cuobjdump 与 nvdisasm

编译后不要急着跑，先看产物里到底有什么：

# 查看可执行文件/库中嵌入的 CUDA 对象
cuobjdump -elf kernel_exe | grep -E "arch|nvdisasm" | head
# 查看 fatbin 中包含哪些架构的 cubin/PTX
cuobjdump -sass kernel_exe | head -20
# 反汇编某个具体内核到 SASS
nvdisasm -c kernel_exe | head -40

读 SASS 的三个关注点：

1. 寄存器使用量（R 数量）：寄存器太多 → 占用率高 → 占位器（occupancy）下降；太少 → 局部变量溢出到 local memory。用 --ptxas-options=-v 在编译期看寄存器与 spill 统计。
2. 内存指令形态：SASS 中 LDG/STG（全局内存）、LDS/STS（共享内存）的比例，判断内核是否内存密集；是否有 LDL/STL（local）说明发生了溢出。
3. 指令混合：FFMA（浮点乘加）、TENSOR 类指令（Tensor Core，如 HMMA/IMMA）是否存在——确认代码真正用上了硬件特性。

# 编译期就获取寄存器/spill/指令统计（关键习惯）
nvcc -arch=sm_90 -Xptxas -v -o kernel kernel.cu
# 输出示例字段：regs、spill loads/stores、used global/local/shared memory

第四站：把编译管线变成优化手段

1. 架构目标决定特性可用性

同样的 matmul 代码，在 sm_80 上只能走 FFMA 路径，在 sm_90 上可以走 WGMMA（warpgroup 矩阵指令）。很多"代码没优化"其实是"架构目标没对准"：

# 检查当前编译产物是否吃到了 Tensor Core 路径
cuobjdump -sass kernel_exe | grep -iE "HMMA|IMMA|WGMMA" | head -3
# 无输出 → 内核可能没走 tensor 路径（源码未用 wmma/mma，或 -arch 太低）

2. PTX 级 vs SASS 级优化

• 源码级（首选）：改算法、改内存访问模式、用 __restrict__、共享内存分块——收益最大、可维护；
• PTX 级（中间层）：手写/内联 PTX（如 __syncwarp、特殊指令）——只用于源码无法表达的场合；
• SASS 级（最后手段）：反汇编后手工调整——极少使用，通常用于"确认编译器是否生成了预期指令"，而不是直接改 SASS。

工程观察：90% 的优化问题在源码级就能解决；读 SASS 的最大价值是"验证"——确认你的优化意图真的反映到了机器码（比如确认向量化、确认无 spill、确认走了 tensor 路径），而不是直接去改汇编。

3. 多架构部署时的编译策略

• 训练/推理服务：按实际部署卡型固定 -gencode，只打包必要架构（减少体积、吃满特性）；
• 通用库/工具：多架构 fatbin + 带 PTX，保兼容；
• CI 中固化：把 -gencode 组合写进构建脚本与 CI 检查（如"产物必须包含 sm_90 SASS"），防止团队内各自编译漂移。

编译管线分析清单

• [ ] -gencode 组合与集群卡型清单对齐（含 PTX 兼容层决策）
• [ ] -Xptxas -v 编译期检查寄存器数与 spill，确认无意外溢出
• [ ] cuobjdump -sass 确认关键内核走预期指令路径（tensor/向量化）
• [ ] 多架构产物（fatbin）包含部署所需的全部 SASS（必要时含 PTX）
• [ ] CI/构建脚本固化编译参数，与交付基线（01 章）一致

工程启示

• 编译管线是"最后一层真相"：性能问题在源码层争论不清时，编译产物会给出客观答案——寄存器、spill、指令形态一目了然。
• 架构目标 = 特性开关：新架构的特性（Tensor Core 新指令、更大寄存器文件）只有对准 -arch 才生效；部署架构与编译目标不一致是隐性性能损失的主要来源。
• 把验证养成习惯：-Xptxas -v + cuobjdump 是十分钟就能养成的检查习惯，能让优化从"感觉有效"变成"确认有效"。

下一篇预告：内核能高效编译运行后，回到集群整体视角——下一批内容将强化 10 预训练与 13 应用的工程深化（数据管线、训练工程、科学软件交付闭环），敬请期待。