pto-isa A5 向量算子性能指标与 Trace 解析规范：VF 总时间定义、记录字段与 Speedup 计算

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）：

第三层证据的降级使用有一条明确的例外条件：除非用户明确要求 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

这个定义有三个要点值得注意：

1. 跨文件取值：起点（第一个 VF start）取自instr_popped_log.dump，终点（最后一个 VF end）取自instr_log.dump。两个文件分别记录 VF 的 issue/pop 时刻与完成时刻，单独看任何一个文件都得不到完整窗口。
2. 不是逐 VF 累加：该定义不同于把所有vf_execute_time相加。累加得到的是"纯执行时间之和"，会丢掉 VF 之间的排队、issue 间隔与同步等待，从而系统性低估总窗口。
3. 不是单 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.dump：VF start/pop cycle；
• core0.veccore0.instr_log.dump：VF completion cycle、vf_execute_time，通常也包含instr_num。

指标文档对解析工具的要求是：如果仓库提供 parser，优先使用仓库 parser；否则编写小型 task-local parser，并记录精确解析规则。这条规则的意图是让指标定义在跨轮次、跨任务时保持不变，只有解析实现可以按任务适配。

仓库自带 parser 的实际解析规则

仓库中恰好存在这样一个 parser：pipeline_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 metric；
• VF 数量；
• 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-misched=0、关闭--cce-simd-vf-fusion=false），使"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状态；
• mismatches；
• max_abs_err；
• max_rel_err；
• runner 使用的未修改绝对/相对容差。

关键规则是：只有任务原始 golden check 通过后，性能才有效。并且，如果 runner 同时报告 PASS 标记和 mismatch/error 字段，两者都要保留到日志中——因为即使总体判定为 PASS，mismatch 字段的逐轮漂移也是后续诊断精度退化（例如某轮向量化改写引入的舍入差异）的第一手证据。

这与仓库 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 failed；
• correctness failed；
• trace 文件缺失或格式错误；
• 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