pto-isa A5 向量算子性能指标与 Trace 解析规范VF 总时间定义、记录字段与 Speedup 计算【免费下载链接】pto-isaParallel Tile Operation (PTO) is a virtual instruction set architecture designed by Ascend CANN, focusing on tile-level operations. This repository offers high-performance, cross-platform tile operations across Ascend platforms.项目地址: https://gitcode.com/cann/pto-isa本文以 pto-isa 仓库中 A5 代际向量算子CCE/PTO VF优化的指标参考文档为核心完整展开其中的测量权威边界、VF 总时间VF total统一定义、CAModel 风格 trace 文件解析规则、必须记录的性能与正确性字段以及 Speedup/Benchmark Percent 的计算口径。读完本文你能在不做任何臆测的前提下把一次 NPU 运行、仿真器 trace 或 costmodel 输出的性能数字转化为可复现、可归因、可写入 round log 的结构化结论并知道哪些数字在什么条件下是无效的。测量权威边界先分清哪类数字有资格作为性能结论在 A5 VF 优化流程中性能数字来自多种链路但它们的权威等级并不相同。指标文档在开篇就确立了三层权威边界见 metrics.md层级来源权威等级Golden correctness runner任务自带的正确性校验任何性能结论之前必须通过是硬性门禁任务声明的 benchmark runnerCAModel、CPU simulator、NPU run、profiler 输出、仓库 costmodel 或 task-local runner最终性能依据以任务声明为准PTO costmodel、指令级 simulator trace、profiler 输出、静态指令证据微架构与调度行为分析仅用于理解指令类别、依赖/issue 行为并形成 hypothesis第三层证据的降级使用有一条明确的例外条件除非用户明确要求 model-only 分析或明确将某个 costmodel/simulator runner 定义为 benchmark否则不得把 costmodel 或 simulator timing 当作最终 kernel performance。这一分级与仓库中 skill 主文档的职责划分一致。SKILL.md 指出当需要解析 trace/profiler 日志、报告 speedup 或画图时才读取 metrics.md即指标文档服务的是把原始测量转化为可信结论这一环节而不是瓶颈假设本身后者由同目录下的 bottlenecks.md 承担。VF 总时间的统一定义对于基于 CAModel 仿真的 multi-VF trace指标文档给出了一个必须统一采用的窗口定义VF total core0.veccore0.instr_log.dump 中最后一个 VF end - core0.veccore0.instr_popped_log.dump 中第一个 VF start这个定义有三个要点值得注意跨文件取值起点第一个 VF start取自instr_popped_log.dump终点最后一个 VF end取自instr_log.dump。两个文件分别记录 VF 的 issue/pop 时刻与完成时刻单独看任何一个文件都得不到完整窗口。不是逐 VF 累加该定义不同于把所有vf_execute_time相加。累加得到的是纯执行时间之和会丢掉 VF 之间的排队、issue 间隔与同步等待从而系统性低估总窗口。不是单 VF 局部 latency也不等于只看某一个 VF 的局部时延。VF total 覆盖从第一个 VF issue/pop 到最后一个 VF 完成的总时间窗是衡量向量流水线整体吞吐的公平口径。在仓库的 costmodel 侧这一执行窗口概念有直接对应物。Perf-Sim 用户指南的pipeline_summary.csv字段表中明确写道active_cycles一列是active_end_cycle - active_start_cycle并且use this when comparing with CAModel core/veccore execution windows见 perf-sim-user-guide.md。这说明仓库内部已经在两种测量体系之间建立了可比的窗口口径仿真侧用 pipeline simulator 的 active 窗口仿真器 dump 侧用first VF start 到 last VF end的窗口二者描述的是同一物理量——核心上工作真正在飞行的时间而非事件时间戳的简单差值或 busy cycles 的累加。Trace 文件来源、字段与解析规则两个关键 dump 文件若存在 CAModel 风格的 VF dump 文件典型文件包括core0.veccore0.instr_popped_log.dumpVF start/pop cyclecore0.veccore0.instr_log.dumpVF completion cycle、vf_execute_time通常也包含instr_num。指标文档对解析工具的要求是如果仓库提供 parser优先使用仓库 parser否则编写小型 task-local parser并记录精确解析规则。这条规则的意图是让指标定义在跨轮次、跨任务时保持不变只有解析实现可以按任务适配。仓库自带 parser 的实际解析规则仓库中恰好存在这样一个 parserpipeline_log_analysis.py。它的文档字符串直接说明了 start/end 日志的语义分工Start logs (*.instr_popped_log.dump) carry the issue timestamps; end logs (*.instr_log.dump) carry completion timestamps即 pop 日志携带发射时间戳、end 日志携带完成时间戳——与上文 VF total 定义的两端取值来源一一对应。从源码结构看该 parser 的核心处理链为逐行解析parse_log用正则提取时间戳[\d]、PC、pipeline token、真实助记符位于二进制编码块之后、地址与instr_id同时过滤 SCALAR 流水线的普通指令、MOVEMASK、MTE1 内部搬运、BAR 同步标记等噪声只保留 WAIT_FLAG_DEVI 类同步事件计入 sync 类别。start/end 配对match_start_end优先按instr_id精确配对对缺失 id 的事件回退为顺序配对并在数量不一致时向 stderr 输出[warn] unmatched events...告警并截断到较短一侧——这正是记录精确解析规则要求的可审计行为配对失败不会被静默吞掉。分类与关联将每条指令归入 load/compute/store/sync 类别基于 pipeline 与助记符前缀并通过device_addrs.toml中的缓冲区地址区间把指令关联到具名 buffer最终输出逐指令的 CSV/JSON、按 (core, buffer, op_class) 聚合的 CSV以及可选的 SVG 时间线。也就是说仓库 parser 给出的是一条完整链路原始 dump → 时间戳提取 → start/end 配对id 优先、顺序兜底→ 类别/缓冲区标注 → 结构化输出。task-local parser 若需自写按此结构对齐即可保持指标语义不变。仓库中真实的调用方式run_timeline.sh 展示了 flash attention 场景下 parser 的标准调用python3 ${SCRIPT_DIR}/../scripts/pipeline_log_analysis.py \ --device-addrs ${build}/device_addrs.toml \ --cube-start ${build}/core0.cubecore0.instr_popped_log.dump \ --cube-end ${build}/core0.cubecore0.instr_log.dump \ --vec-start ${build}/core0.veccore0.instr_popped_log.dump \ --vec-end ${build}/core0.veccore0.instr_log.dump \ --out-csv timeline.csv \ --out-json timeline.json \ --out-agg timeline_agg.csv \ --out-svg timeline.svg两点值得注意其一构建产物目录下 cube 与 vector 两套核心各有一对*.instr_popped_log.dump/*.instr_log.dump文件命名与指标文档中描述的core0.veccore0.*完全一致其二vector 侧的 start/end 文件正是计算 VF total 的两端来源--vec-start中第一个有效时间戳与--vec-end中最后一个有效时间戳之差就是该窗口定义在工具链里的具体落点。必须记录的性能字段指标文档要求每轮测量至少记录以下字段first VF start第一个 VF 开始last VF end最后一个 VF 结束total VF latency 或任务声明的 latency/cycle metricVF 数量per-VF execute time如果可用VF instruction count如果可用benchmark reference如果任务提供精确的 runner、command、device/model target 和相关 build flags。最后一项是容易被忽略的测量契约字段不记录 runner、命令与 build flags任何 speedup 都无法归因到候选修改本身。这一点与同目录的 rules.md 相互呼应——后者要求固定 runner、workload、correctness threshold、target device/model 和 build flags例如测量 source-level scheduling 时默认开启-mllvm -cce-aicore-vec-misched0、关闭--cce-simd-vf-fusionfalse使build flags 与测量契约不同这种失效情形可以被显式识别。round log 层面的字段清单rules.md也把任务声明 total或可用时 CAModel-style first VF start、last VF end、total、per-VF execute、instr counts列为必须记录项与上表逐条对应。必须记录的正确性字段性能有效性的前置门禁指标文档规定使用任何性能数字之前必须记录 task-local golden 结果。可用时包括最终PASS/FAIL状态mismatchesmax_abs_errmax_rel_errrunner 使用的未修改绝对/相对容差。关键规则是只有任务原始 golden check 通过后性能才有效。并且如果 runner 同时报告 PASS 标记和 mismatch/error 字段两者都要保留到日志中——因为即使总体判定为 PASSmismatch 字段的逐轮漂移也是后续诊断精度退化例如某轮向量化改写引入的舍入差异的第一手证据。这与仓库 skill 的正确性门禁流程一致。rules.md 规定的候选处理顺序是build candidate → 运行 correctness/golden validation →correctness 通过后才解析 performance → 追加 round log同时明令严格使用 task-local tolerance不得放宽 threshold 让 candidate 变 valid且当仓库 runner 没有目标算子的 golden check 时应实现 task-local golden checker 而不弱化容差。Speedup 与 Benchmark Percent 的计算口径对于 latency 类指标越低越好。指标文档给出的两个标准公式为speedup_vs_baseline baseline_cycles / candidate_cycles performance_vs_benchmark_percent benchmark_cycles / candidate_cycles * 100其中speedup_vs_baseline衡量候选相对 baseline 的加速比分子是 baseline 周期数、分母是 candidate 周期数大于 1 即有收益performance_vs_benchmark_percent衡量候选相对任务声明 benchmark 的达成度。当 benchmark 是 latency 值时超过 100% 表示 candidate 快于 benchmark因为分母是 candidate比值越高说明 candidate 周期越少。这两个公式刻意统一了latency 越低越好的方向性避免在日志中出现周期数变小却被写成性能下降的表述混乱。在记录时还应同时保留两个参照系——rules.md 的 round log 字段中明确要求同时记录candidate vs previous round和candidate vs best-so-far即每一轮既要与上一有效轮次比较以判断局部进退也要与历史最优比较以维护 best-so-far 基线。稳定性单次 run 与重复 run 的判定如果仓库 timing 路径是确定性的单次 run 可以接受如果 rebuild/rerun 之间 timing 存在波动应标记为 noisy并重复足够次数以确认代表性结果。判定确定性本身应来自对测量链路的理解基于静态 trace dump 的离线解析如上文 VF total 的定义时间戳直接来自 dump 文件通常是确定性的重跑不改变结果而涉及实机 NPU run 或带调度的仿真则更可能出现波动。对 noisy 场景重复次数应足以观察波动范围后再取代表性值而不是默认采信某一次偶然的最优值。无效指标清单以下任一情况出现时本轮性能数字无效不得进入 round log 的有效对比build failedcorrectness failedtrace 文件缺失或格式错误build flags 与测量契约不同workload 或 threshold 未经用户批准被修改。这份清单与 SKILL.md 的不可违反的规则构成闭环build failed 或 correctness failed 的结果不得作为有效性能不得为了制造 speedup 而弱化 correctness threshold、workload size、build flags 或 benchmark logic。换言之无效指标不是数据质量差的程度问题而是二值的合规判定——只要命中清单中任何一条该轮结果只能用于诊断不能作为 candidate 的收益证据。小结指标定义在优化流程中的位置综合 SKILL.md 的四步主流程建立测量契约 → 逐轮执行 → 记录每一轮 → 按证据切换方向指标文档承担的是测量契约与记录两步中的判定标准它决定了哪些数字可作为最终依据权威边界、multi-VF 窗口如何定义VF total、日志必须包含什么性能字段 正确性字段、收益如何量化两个公式、以及哪些数字一票否决无效清单。与之配套的仓库工具——pipeline_log_analysis.py 的 id 优先配对解析、run_timeline.sh 的 cube/vector 双端调用、以及 Perf-Sim 指南中active_cycles与 CAModel 窗口的可比口径——共同保证了同一套指标定义在不同测量链路上都能落到可执行的解析规则上。遵循这套契约性能结论就能做到可复现记录 runner 与 flags、可归因固定契约下的单 hypothesis 轮次、可验证correctness 门禁前置这正是 A5 向量算子迭代优化中避免伪 speedup的核心机制。【免费下载链接】pto-isaParallel Tile Operation (PTO) is a virtual instruction set architecture designed by Ascend CANN, focusing on tile-level operations. This repository offers high-performance, cross-platform tile operations across Ascend platforms.项目地址: https://gitcode.com/cann/pto-isa创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考