需用ncu -k "kernel_name" --metrics sm__warps_launched,sm__inst_executed ./app精准捕获单个核函数寄存器使用情况，核心指标是sm__inst_executed / sm__warps_launched比值，显著低于32表明寄存器超限导致活跃warp下降。
如何用 ncu 命令精准捕获单个核函数的寄存器使用情况
直接运行 ncu 默认会采集整个应用生命周期的 GPU 活动，寄存器统计（如 sms__sass_average_data_bytes_per_sector_mem_shared_op_ld 这类指标）会被平均化，无法定位到具体核函数。必须用过滤机制聚焦目标核函数。
实操建议：
- 先用
ncu --set full --page detail --target-processes all ./your_app跑一次，从输出里找到目标核函数的完整 demangled 名（例如_Z12my_kernel_v2IfEviT_），注意它可能带模板参数和命名空间 - 用
-k参数精确匹配：ncu -k "_Z12my_kernel_v2IfEviT_" ./your_app。多个核函数可用逗号分隔：-k "func1,func2" - 若核函数名含特殊字符或不确定完整符号，可配合
--kernel-name-regex，但正则匹配容易误伤，优先用-k - 避免用
--launch-skip或--launch-count代替-k—— 它们按启动序号过滤，而同一核函数可能被多次 launch，序号不稳定
寄存器占用的核心指标是哪个？怎么看是否超标
Nsight Compute 不直接报告“用了多少寄存器/线程”，而是通过 sm__inst_executed 和 sm__warps_launched 推算实际寄存器压力，最关键的观测指标是：
-
sm__sass_average_data_bytes_per_sector_mem_shared_op_ld：间接反映寄存器 bank conflict 程度，值越高说明 bank 冲突越严重（常见于寄存器复用密集场景） -
sm__inst_executed/sm__warps_launched：比值接近 32 表示 warp 全速执行；若显著低于 32（如 24），大概率是寄存器超限导致活跃 warp 数下降 - 在 GUI 中打开 “Source” 页面，查看每行代码旁的 “Register Usage” 列（需编译时加
-lineinfo），它显示该行对应指令实际使用的寄存器数量
注意：nvcc -Xptxas -v 编译时打印的 “Used 64 registers” 是静态分析上限，而 ncu 报的是运行时实际分配量，二者可能不一致——尤其当 kernel 含分支、模板特化或内联函数时。
NVIDIA Kimi Vision
下载
通过 NVIDIA NIM API 调用 Kimi K2.5 视觉模型分析图像，非常适合为 MiniMax M2.5、GLM-5 等非视觉模型赋予视觉能力。
立即学习“C++免费学习笔记（深入）”；
为什么开了 --set full 还看不到寄存器 bank conflict 数据
--set full 并不包含所有硬件事件，寄存器 bank 相关事件属于低开销采样集，需显式启用：
- bank conflict 必须加
--metrics sm__sass_average_data_bytes_per_sector_mem_shared_op_ld,sm__sass_average_data_bytes_per_sector_mem_shared_op_st - 若只关心寄存器总量而非 bank 行为，用
--metrics sm__warps_launched,sm__inst_executed,sm__inst_issued就够了 - 某些 A100/V100 上，
sm__sass_*类事件需 root 权限或开启 perfmon（sudo nvidia-smi -r后再跑ncu） - RTX 4090 等 Ada 架构默认禁用部分 sass 事件，需额外加
--unified-memory-profiling on才能解锁完整指标
常见陷阱：编译选项与 profiling 结果不一致
寄存器使用高度依赖编译器优化行为，ncu 结果和你本地编译环境强耦合：
- 务必用和 profiling 时完全相同的
nvcc命令重编译，尤其注意：-O3vs-O0、-use_fast_math、-Xptxas -dlcm=ca等都会大幅改变寄存器分配 - Debug 版本（
-G）强制增加寄存器用于变量存储和调试信息，寄存器用量比 Release 高 2–3 倍，切勿用 Debug build 做性能分析 - 若 kernel 被
__forceinline__或模板展开，ncu可能将其识别为多个不同符号，此时需用--kernel-name-regex匹配通用前缀，再人工筛选
寄存器瓶颈往往藏在看似简单的循环展开或数组索引计算里，ncu 给出的数字只是表象，真正要盯住的是 “为什么这一行让寄存器用量突然跳变”——这需要把 source view、sass disassembly 和 metrics 三者对齐看。
