@cannbot-plugin/cannbot-harness 0.0.0-stage → 0.1.5

package/assets/ops-direct-invoke/skills/ops-simulator/references/performance-metrics-reference.md

@@ -0,0 +1,350 @@
+# npusim Performance Metrics Reference
+
+Data source: `summary.json` (located at `<npusim_output>/report/results/kernel_*_reports/summary.json`)
+
+Read and interpret all non-empty sections before drawing conclusions.
+
+---
+
+## Sections Overview
+
+| Section | Purpose | Always present? |
+|---------|---------|-----------------|
+| `kernel_info` | Kernel duration and hardware configuration | yes |
+| `pipe_utilization.pipeline_util_summary` | Per-pipeline utilization as fraction [0, 1] | yes |
+| `top_level_diagnosis` | Immediate bottleneck orientation | yes |
+| `scalar_instructions` | Register spill detection per subcore | yes |
+| `aiv_vector_instructions` | Vector compute efficiency | yes |
+| `cache` | Instruction and data cache misses | **may be absent** |
+| `bandwidth` | DMA transfer efficiency per transport | **may be absent** |
+| `pipeline_overlap` | Parallelism between pipeline pairs | yes |
+| `simd_vf_metrics` | Per-VF code-shape metrics (granularity, timing, IPC, overhead, work, stalls, pattern_signals) | yes (empty `{}` when kernel has no SIMD VFs) |
+
+> **Missing-section note**: `cache` and `bandwidth` may be absent from `summary.json`. If a section is absent, just don't factor it into the analysis — skip steps that depend on it and use the fallback signals (`pipe_utilization` + `pipeline_overlap`); each issue page documents the fallback when applicable. The `simd_vf_metrics` block follows a third pattern: always present when the kernel has SIMD VFs (`__simd_vf__` + `asc_vf_call`), empty `{}` otherwise — if `{}`, §6 in `performance-issues-aiv.md` is a no-op.
+
+---
+
+## 1. `kernel_info`
+
+| Field | Description |
+|-------|-------------|
+| `ai_core_active` | Number of AI cores whose profiling data is available for analysis (see note below) |
+| `kernel_total_clocks` | Wall-clock duration of the kernel in ticks — **primary optimization target: minimize** |
+| `kernel_instructions_executed` | Total instructions across all cores — secondary optimization signal |
+| `frequency_ghz` | Core frequency in GHz. Use `kernel_total_clocks / frequency_ghz` to convert ticks to microseconds (μs) for cross-tool comparison (e.g., with msprof `Task Duration`). |
+
+**Optimization targets**:
+- `kernel_total_clocks` — the direct measure of kernel latency. Every optimization should be validated against this number. Lower is always better.
+- `kernel_instructions_executed` — secondary signal. A decrease confirms redundant work was eliminated. An increase alongside a decrease in clocks is acceptable (e.g., loop unrolling trades more instructions for better pipelining).
+
+> **Note on `ai_core_active`**:
+> - `ai_core_active = 1` can mean either (a) the kernel genuinely ran on one core, or (b) profiling data was captured for only one core even if multiple were active. In case (b), `imbalance_ratio` will be 1.0 and `per_core` will not appear, but real multi-core imbalance may still exist.
+> - `ai_core_active > 1` but `per_core` arrays contain fewer entries (often just one): the kernel was launched with `blockDim = ai_core_active` cores but the simulator only traced a subset. `imbalance_ratio` is still meaningful (it reflects the launch's actual span), but `per_core` won't let you locate the slow core — use the structural check from `performance-issues-general.md §1` / `§2` (compare `(m × n) / (baseM × baseN)` against `blockDim`).
+>
+> **Implication for inter-core optimizations**: when `per_core.length < ai_core_active`, cross-core hardware effects (L2 sharing between cores in a scheduling wave, HBM contention) are only partially modelled. Optimizations whose primary benefit is *inter-core* spatial locality (SWAT scheduling, cross-core scale preload) will show a smaller measured win on npusim than on real silicon. Treat single-digit-percent improvements from these optimizations as confirmation that the direction is right, not as the full impact.
+
+---
+
+## 2. `pipe_utilization.pipeline_util_summary`
+
+Per-pipeline activity as a fraction [0, 1] of `kernel_total_clocks`. Only non-zero pipelines appear.
+
+Each entry: `{SUBCORE}_{PIPE}: { mean, min, max }` — always present.
+
+When `ai_core_active > 1`, each entry also contains a `per_core` array:
+
+```json
+"AIC_CUBE": {
+    "mean": 0.8934,
+    "max":  0.9712,
+    "min":  0.7201,
+    "per_core": [0.9712, 0.9120, 0.7201, 0.8703]
+}
+```
+
+`per_core[i]` is the utilization of pipeline `{SUBCORE}_{PIPE}` on core `i`. The array length is ≤ `ai_core_active` (typically equals it, but may be shorter when the simulator traces only a subset of cores — see the note on `ai_core_active` above). Use it to identify which specific core is the outlier when `imbalance_ratio > 1.3`.
+
+> **Skip `per_core` unless imbalance is flagged.** When `imbalance_ratio ≤ 1.3`, `mean` / `max` / `min` are sufficient — do not read the (potentially dozens of) `per_core` entries. Estimate per-pipe spread cheaply from `max − min`; only drill into `per_core` to locate the outlier core index once `imbalance_ratio > 1.3` has already justified it.
+
+### Subcore types
+
+| Subcore | Pipelines | Role |
+|---------|-----------|------|
+| `AIC` | `SCALAR`, `CUBE`, `MTE1`, `MTE2`, `FIXP` | AI Cube core |
+| `AIV0`, `AIV1`, … | `SIMD`, `SIMT`, `SCALAR`, `MTE2`, `MTE3` | AI Vector cores |
+
+> **`AIVx_SIMT` appears only when the kernel uses the SIMT programming model** (`Simt::VF_CALL`). It is a **separate pipeline from `AIVx_SIMD`** — SIMT work does **not** show up under `AIVx_SIMD.mean` (which can stay ≈ 0 even while SIMT is the dominant pipe). SIMT execution inflates the shared `aiv_vector_instructions.RVECEX_count` and is measured by the `SIMT_*IPC` fields (see §5).
+
+### Utilization interpretation
+
+| Dominant pipeline | Bound type |
+|-------------------|------------|
+| `AIC_CUBE` mean > 0.80 | CUBE Bound |
+| `AIVx_SIMD` mean > 0.50 | VECTOR Bound |
+| `AIVx_SIMT` highest | SIMT Bound (thread-parallel irregular / serial-decomposed workload — see aiv §5) |
+| `AIC_MTE2` or `AIVx_MTE2` highest | MTE2 Bound |
+| `AIC_MTE1` highest | MTE1 Bound |
+| `AIC_FIXP` highest | FIXPIPE Bound |
+| `AIC_SCALAR` or `AIVx_SCALAR` significantly above CUBE/VECTOR | SCALAR Bound |
+
+---
+
+## 3. `top_level_diagnosis`
+
+| Field | Description | Thresholds |
+|-------|-------------|------------|
+| `dominant_pipeline` | Pipeline key with the highest `mean` utilization | — |
+| `dominant_pipeline_util` | Its utilization as fraction [0, 1] | — |
+| `imbalance_ratio` | `max_core_duration / min_core_duration` | ≤ 1.3 balanced · 1.3–2.0 mild · > 2.0 severe |
+
+`imbalance_ratio > 1.3` signals uneven tiling across cores. Resolve before chasing pipeline bounds.
+
+---
+
+## 4. `scalar_instructions`
+
+One entry per subcore: `AIC`, `AIV0`, `AIV1`, …
+
+| Field | Description | Threshold |
+|-------|-------------|-----------|
+| `total_count` | Total scalar instructions |  |
+| `load_count` | Scalar load instructions |  |
+| `store_count` | Scalar store instructions |  |
+| `load_store_ratio` | `(load + store) / total` | < 0.30 normal · ≥ 0.30 register spill suspected |
+
+`load_store_ratio ≥ 0.30` is the primary indicator of register spill causing SCALAR Bound. Combine with `cache.dcache_refill_count` to gauge severity.
+
+---
+
+## 5. `aiv_vector_instructions`
+
+Aggregate over all AIV subcores (they typically execute the same code).
+
+| Field | Description | Thresholds |
+|-------|-------------|------------|
+| `RVECEX_count` | Compute (execute) instructions | — |
+| `RVECLD_count` | UB read-back instructions | — |
+| `RVECST_count` | UB write-back instructions | — |
+| `ub_traffic_ratio` | `(RVECLD + RVECST) / RVECEX` | < 1.0 acceptable · ≥ 1.0 excessive UB traffic → VF RegAPI |
+| `SIMD_ScalarIPC` | Scalar IPC within the SIMD part of VF | — |
+| `SIMD_ExecIPC` | Compute IPC for SIMD; dual-issue max ≈ 2.0 | < 1.2 poor · 1.2–1.5 moderate · > 1.5 good |
+| `SIMD_LdStIPC` | Load/store IPC within SIMD | — |
+| `SIMT_ExecIPC` | Compute IPC for the SIMT part of VF | — |
+| `SIMT_LdStIPC` | Load/store IPC within SIMT | — |
+| `SIMT_BranchIPC` | Branch instruction IPC within SIMT | — |
+
+`ub_traffic_ratio` is the key trigger for VF RegAPI recommendation. `SIMD_ExecIPC` rises after RegAPI is applied.
+
+> **Note on shared instruction counters**: `RVECEX_count`, `RVECLD_count`, and `RVECST_count` are shared counters — the profiler does not split them between SIMD and SIMT. `ub_traffic_ratio` is therefore an aggregate over both sub-units. The IPC fields (`SIMD_ExecIPC`, `SIMT_ExecIPC`, etc.) are tracked independently per sub-unit.
+
+---
+
+## 6. `cache`
+
+| Field | Description | Action threshold |
+|-------|-------------|-----------------|
+| `icache_refill_count` | Instruction cache miss count | > 0 → consider icache prefetch |
+| `icache_refill_ticks` | Ticks lost to icache misses | > 0 → quantify cost |
+| `dcache_refill_count` | Data cache misses (register spill reaching GM) | > 0 → HIGH PRIORITY: fix spill root cause |
+| `dcache_refill_ticks` | Ticks lost to dcache misses | `null` = counter unavailable |
+
+`dcache_refill_count > 0` means register spill is reaching Global Memory (~hundreds of cycles per miss). This is very expensive and should be fixed before any other optimization.
+
+---
+
+## 7. `bandwidth`
+
+One entry per transport channel. Key name pattern: `{SUBCORE}_{PIPE}_{SRC}_TO_{DST}`.
+
+| Field | Description | Threshold |
+|-------|-------------|-----------|
+| `total_gbps` | Effective bandwidth over kernel duration | — |
+| `bandwidth_utilization` | `total_gbps / hardware_peak_gbps` | < 0.70 when pipeline is Bound → transport is inefficient |
+| `avg_transaction_gbps` | Bandwidth per individual DMA request | Very low → small DMA granularity; double buffer may not help |
+| `transaction_count` | Number of DMA transactions | `= 1` with anomalous `avg_transaction_gbps` → ignore, not statistically meaningful |
+
+**Hardware peak bandwidth for Ascend 950 (dav-3510)**: ~1600 GB/s HBM. If `bandwidth_utilization` is missing from the summary but `total_gbps` is present, compute it as `total_gbps / 1600`. On-chip transports (L1↔L0, L0C↔UB) have much higher peaks and are typically not the limiting factor — focus on HBM-touching transports (`*_OUT_TO_*` / `*_TO_OUT`).
+
+### Key transport channels
+
+| Key | Data path | Relevant bound |
+|-----|-----------|---------------|
+| `AIC_MTE2_OUT_TO_L1` | Global Memory → L1 | CUBE Bound / MTE2 Bound (AIC) |
+| `AIC_MTE1_L1_TO_L0A` | L1 → L0A (matrix A) | MTE1 Bound |
+| `AIC_MTE1_L1_TO_L0B` | L1 → L0B (matrix B) | MTE1 Bound |
+| `AIC_FIXPIPE_L0C_TO_L1` | L0C → L1 | FIXPIPE Bound |
+| `AIC_FIXPIPE_L0C_TO_OUT` | L0C → Global Memory (direct output, no L1 staging) | FIXPIPE Bound |
+| `AIC_FIXPIPE_L0C_TO_UB0` | L0C → UB0 (cross-core feed to AIV) | FIXPIPE Bound |
+| `AIC_FIXPIPE_L0C_TO_UB1` | L0C → UB1 (cross-core feed to AIV) | FIXPIPE Bound |
+| UB0/UB1 → L1 | UB to L1 transfer (key name varies by pipe) | Present when AIC reads AIV-side UB |
+| `AIVx_MTE2_OUT_TO_UB` | Global Memory → UB | VECTOR Bound / MTE2 Bound (AIV) |
+| `AIVx_MTE3_UB_TO_OUT` | UB → Global Memory | MTE3 Bound |
+
+Only the active transports appear in `bandwidth`.
+
+---
+
+## 8. `pipeline_overlap`
+
+Fraction of time two pipelines run simultaneously:
+`overlap = intersect(A_busy, B_busy) / union(A_busy, B_busy)`
+
+| Threshold | Interpretation |
+|-----------|---------------|
+| < 0.05 | No overlap — double buffer not working or not enabled |
+| 0.05–0.30 | Partial overlap |
+| > 0.30 | Effective overlap |
+| > 0.60 | Good overlap |
+
+> **`VEC` in overlap keys = the VF-function pipe**, not a fourth instruction type. On the AIV side, SIMD and SIMT instructions only ever execute **inside a VF function** (`Simt::VF_CALL` / vector VF). The profiler measures overlap at VF-function granularity — one `VEC` interval wraps that function's SIMD *or* SIMT instructions — so the overlap key operand is `VEC`, not `SIMD`/`SIMT`. Thus `AIV0_MTE2_vs_AIV0_VEC` = "MTE2 overlapped with VF compute (whichever of SIMD/SIMT ran inside)". The separate `AIVx_SIMD` / `AIVx_SIMT` entries in `pipe_utilization` (§2) still report where instructions executed; `VEC` exists only in `pipeline_overlap`.
+
+### Key pipeline pairs
+
+| Key | Meaning | Low overlap action |
+|-----|---------|-------------------|
+| `AIC_MTE2_vs_AIC_CUBE` | GM→L1 vs CUBE compute | Double buffer on L1 |
+| `AIC_MTE1_vs_AIC_CUBE` | L1→L0 vs CUBE compute | Double buffer on L0A/L0B |
+| `AIC_FIXP_vs_AIC_CUBE` | FIXPIPE output vs CUBE compute | Low → CUBE stalling waiting for L0C to drain; increase N-axis tile size |
+| `AIC_SCALAR_vs_AIC_CUBE` | Scalar dispatch vs CUBE compute | Low → serial scalar/CUBE (backpressure); High + SCALAR dominant → scalar IS cause |
+| `AIV0_MTE2_vs_AIV0_VEC` | GM→UB vs VECTOR compute | Double buffer (check bufNum=2, EnQue/DeQue pairing) |
+| `AIV0_MTE3_vs_AIV0_VEC` | UB→GM vs VECTOR compute | Increase ubFactor |
+| `AIV0_SCALAR_vs_AIV0_VEC` | Scalar dispatch vs VECTOR compute on AIV0 | Low → scalar overhead serial with vector; check loop scalar overhead |
+| `AIV1_SCALAR_vs_AIV0_VEC` | Scalar on AIV1 vs VECTOR on AIV0 | See note below |
+| `AIC_CUBE_vs_AIV0_VEC` | Cube vs Vector inter-core | `= 0.0` → Cube/Vector inter-core pipeline not used |
+
+> **Note on `AIV1_SCALAR_vs_AIV0_VEC`**: the key name in `summary.json` crosses cores (AIV1 scalar vs AIV0 VF compute). Treat it analogously to `AIV0_SCALAR_vs_AIV0_VEC` — low overlap indicates the two subcores have serial scalar/VF phases.
+
+> **Note on compute-light (DMA-bound) kernels — no VF compute**: the `VEC` operand is the VF-function pipe (see the note above the key-pairs table). In a kernel whose real work is scalar + DMA (gather/scatter, histogram, index remap) there is **no VF compute at all** — both `AIVx_SIMD.mean` and `AIVx_SIMT.mean` are ≈ 0, so the `VEC` pipe is idle and every `*_vs_VEC` overlap stays near zero **even when double buffering is working correctly**. The overlap that actually matters (MTE2↔MTE3) has **no field** in `summary.json`. When `AIVx_SIMD.mean < 0.05` **AND** `AIVx_SIMT.mean < 0.05`:
+> - **Diagnosis** (which pipe dominates) — use `AIVx_MTE2.mean` / `AIVx_MTE3.mean`; ignore the `*_vs_VEC` overlaps.
+> - **Verification** of double buffering / store batching — use **`kernel_total_clocks` ↓ only**. The MTE utilizations may stay flat **or even rise** (the same busy time packs into fewer total clocks, and `util = busy / total_clocks`), and the `*_vs_VEC` overlaps stay ~0. Flat/rising MTE utilization and unchanged overlap are **not** signs the fix failed — confirm by the clock drop.
+> - **Once the kernel gains VF compute** (e.g. a SIMT rewrite, aiv §5), the `VEC` pipe becomes active and `*_vs_VEC` overlaps become meaningful again.
+
+---
+
+## 9. `simd_vf_metrics`
+
+Per-VF code-shape metrics for kernels that use the SIMD VF (vector function) programming model (`__simd_vf__` + `asc_vf_call<>`). Block is **always present** when the kernel has SIMD VFs; absent (or `{}`) otherwise. Used by aiv §6 (SIMD VF Code-Shape Patterns) in `performance-issues-aiv.md` to detect code-shape patterns (broadcast fragmentation, reduce serial dependency, binary folding) — distinct from pipeline-bound diagnosis in §1–§5.
+
+> **Always-present note**: `simd_vf_metrics` is generated by npusim and is appended after `pipeline_overlap`. If the kernel has no SIMD VF functions, the block is `{}` and all §6 aiv triggers are no-ops.
+
+### Granularity
+
+| Field | Description | Threshold |
+|-------|-------------|-----------|
+| `vf_distinct_count` | Number of distinct call sites that launch VF functions | info field |
+| `vf_total_executions` | Total VF invocations — raw count, affected by multi-core and npusim profiling behavior. Use `vf_executions_per_core` for thresholds. | info field |
+| `vf_active_cores` | Number of distinct AIV subcores that executed VF calls — self-consistent with `vf_total_executions` (both from the same profiling data) | info field |
+| `vf_executions_per_core` | `vf_total_executions / vf_active_cores` — normalized VF calls per AIV subcore. Self-consistent: both numerator and denominator from the same profiling data, so ratio is stable regardless of how many physical cores are active. | `> 8` → aiv §6.1 secondary (fragmentation); `≤ 8` → aiv §6.2 guard; `(5, 8]` grey zone — do not re-trigger |
+| `vf_max_executions_per_call_site` | Max times any single call_site fired | info field — not used in aiv §6.1 trigger |
+
+### Timing
+
+| Field | Description | Threshold |
+|-------|-------------|-----------|
+| `vf_avg_cycles` | Average VF duration in ticks | drops after aiv §6.1 fold (one VF does more work, total clocks drop more) |
+| `vf_max_cycles` | Longest single VF duration | — |
+| `vf_min_cycles` | Shortest single VF duration | — |
+| `vf_total_cycles` | Sum of all VF durations — denominator for overhead and stall ratios | — |
+
+### IPC
+
+| Field | Description | Threshold |
+|-------|-------------|-----------|
+| `vf_min_exec_ipc` | Min `ExecIPC` across all VF invocations — worst VF (low → serial dependency, reduce) | `< 0.7` (corroborating aiv §6.2) |
+
+> **Average IPC**: `vf_avg_exec_ipc` is **not** in `simd_vf_metrics` — it is reported as `aiv_vector_instructions.SIMD_ExecIPC` (see §5). Both derive from the same VF profiling data. The primary classifier for latency-bound in aiv §6 (SIMD VF Code-Shape Patterns) is `simd_vf_metrics.vf_stall_ratio` (see Stall below); `SIMD_ExecIPC` is the secondary corroborating metric.
+
+### Overhead
+
+| Field | Description | Threshold |
+|-------|-------------|-----------|
+| `rvecsu_count` | Aux-scalar instruction count for VF (address arithmetic feeding VF parameters) | — |
+| `rvecsu_cycles` | Cycles spent in aux-scalar instructions | — |
+| `pushq_count` | `PUSHQ` instruction count (proxy for parameter-buffer pushes) | — |
+| `pushq_cycles` | Cycles spent in `PUSHQ` (proxy for PB-push cycles) | — |
+| `pushq_overhead_ratio` | `pushq_cycles / vf_total_cycles` — share of VF time spent on PB parameter passing | info field (always > 1.0 in npusim; not discriminating) |
+| `rvecsu_overhead_ratio` | `rvecsu_cycles / vf_total_cycles` — share of VF time spent on aux scalar | **`> 0.15` → aiv §6.1 primary trigger** |
+
+### Work-per-VF
+
+| Field | Description | Threshold |
+|-------|-------------|-----------|
+| `rvecex_per_vf` | `RVECEX_count / vf_total_executions` — execute instructions per VF invocation | `> 4` → long chain (possible aiv §6.3 binary foldable for `reduce_sum_ar`) |
+| `rvecex_cycles_per_vf` | Execute cycles per VF | drops after aiv §6.3 binary fold (fewer Add instructions) |
+
+> **Dedup note**: `rvecex_per_vf` may be inflated when `vf_total_executions` is deduplicated by npusim. This does not affect aiv §6.3 because §6.3 requires `rv_vcadd > 0`, which excludes broadcast patterns. For reduce kernels, `rvecex_per_vf` is accurate.
+
+### Pattern signals
+
+Per-instruction-name counts for code-shape pattern detection (reduce / elemwise). Exposed directly in `summary.json` so aiv §6 triggers don't depend on a sibling report file. All fields default to `0` if the instruction name is absent.
+
+| Field | Description | Used by |
+|-------|-------------|---------|
+| `pattern_signals.rv_vmax` | `Max` vector instruction count | aiv §6.2 (`reduce_max_like`) |
+| `pattern_signals.rv_vcmax` | Inside-vector `ReduceMax` count (ar-axis signal) | aiv §6.2 (`reduce_max_like`) |
+| `pattern_signals.rv_vadd` | `Add` vector instruction count | aiv §6.2 / §6.3 (`reduce_sum_like`) |
+| `pattern_signals.rv_vcadd` | Inside-vector `ReduceSum` count (ar-axis signal) | aiv §6.3 (required) |
+| `pattern_signals.rv_vstui` | Unaligned scalar store count (ra-axis signal) | aiv §6.2 (`reduce_sum_like`) |
+| `pattern_signals.rv_vst` | `StoreAlign` vector store count — used to distinguish broadcast from reduce: `rv_vst / (rv_vadd + rv_vmax) > 0.5` → broadcast (every result stored, no accumulator); `≤ 0.5` → reduce (accumulator, few stores) | aiv §6.2 (reduce pattern guard: `≤ 0.5` required) |
+| `pattern_signals.rv_vmul` | `Mul` vector instruction count | info field (elemwise signal) |
+| `pattern_signals.rv_vmul_s` | Scalar-multiply (`Muls`) count | info field (elemwise signal, AXPY) |
+
+### Stall
+
+Stall metrics measure ticks **strictly inside** one VF call where **no vector-pipe instruction** (RVECEX, RVECLP, RVECSU, RVECST, RVECLD) starts executing. For each tick in the VF's execution range, the reporter checks if any vector instruction starts at that tick; if none — stall tick. Non-vector instructions inside VF are ignored — they do not count as "issue". Ticks between VF calls (while main scalar prepares parameters) are **excluded** — those are captured by `rvecsu_overhead_ratio`.
+
+> **Example**: VF spans ticks `[10001, 10526]`. At tick 10050, no vector instruction starts (data-dependency stall). `vf_total_stall_cycles += 1`. If ticks 10050–10068 all have no vector issue — 19 stall ticks accumulated, and when issue resumes at 10069 — `vf_stall_event_count += 1` (one stall run completed).
+
+| Field | Description | Threshold |
+|-------|-------------|-----------|
+| `vf_stall_event_count` | Number of stall runs (transitions from issue to no-issue) across all VFs — each time a consecutive stall sequence ends, this increments. Orthogonal to `vf_stall_ratio`: measures stall **frequency** (how many times stall started), not **intensity** (how long total stall was) | corroborating: `vf_stall_event_count / vf_total_executions > 10` → real serial chain exists regardless of `vf_stall_ratio` |
+| `vf_total_stall_cycles` | Total number of stall ticks across all VFs (each tick where no vector instruction was issued) | — |
+| `vf_stall_ratio` | `vf_total_stall_cycles / vf_total_cycles` — share of VF ticks where no vector instruction was issued | **primary trigger for aiv §6.2**: `> 0.20` latency-bound (optimise via multi-accumulator unroll). Grey zone `[0.10, 0.20]` — do not re-apply aiv §6.2 |
+
+> **Starting thresholds note**: `vf_stall_ratio` thresholds `0.10` / `0.20` are starting points. Verify against production shapes before treating them as final.
+
+### Known limitations of single-threshold triggers
+
+`vf_stall_ratio` is a ratio of stall ticks to total VF ticks. It works well for strong serial chains (long serial chains where stall easily exceeds 20% of VF time) but **normalizes away the chain-length signal**: a short chain in a long VF can produce a sub-threshold ratio even though the chain is real and optimization yields a measurable gain.
+
+Practical implications for aiv §6.2 in `performance-issues-aiv.md`:
+- **Strong chains (≥ 8 serial steps)**: reliably caught by `vf_stall_ratio > 0.20`. Apply aiv §6.2.
+- **Weak chains (3–7 serial steps, e.g. `reduce_*_ar`)**: may fall into the grey zone `[0.10, 0.20]`. The agent should NOT auto-skip these — instead use `vf_stall_event_count` as a corroborating signal: if `vf_stall_event_count / vf_total_executions > 10`, a serial chain exists regardless of `vf_stall_ratio`. For `reduce_sum_like`, also check aiv §6.3 (binary folding) which has an independent trigger based on `rvecex_per_vf` and pattern, not on stall metrics.
+- **Post-optimization reduce**: lands below `0.10` (correctly — kernel is optimized). Distinguish via pattern filter, not via stall metrics alone.
+
+This is a **documented limitation**, not a bug: the boolean trigger catches "obvious" cases; weak cases require either (a) a corroborating metric (`vf_stall_event_count`), (b) an independent pattern-based trigger (aiv §6.3 binary folding), or (c) explicit source inspection for short accumulator chains.
+
+---
+
+## Analysis Priority
+
+Apply this order strictly. Fixing a later step before an earlier one usually changes nothing because the upstream problem still hides the metric you'd use to verify.
+
+1. **`imbalance_ratio`** ([general §1](performance-issues-general.md)) — fix load imbalance first; pipeline metrics are unreliable when cores are unbalanced.
+2. **Kernel utilization sanity** ([general §2](performance-issues-general.md)) — if `top_level_diagnosis.dominant_pipeline_util < 0.50` **AND** all `pipeline_overlap.*` values are near zero (`< 0.10`) **AND** the compute pipe is idle — for a **Cube** kernel `AIC_CUBE.mean < 0.10`, for a **pure-vector** kernel `AIVx_SIMD.mean` **and** `AIVx_SIMT.mean` both `< 0.05` — the kernel isn't doing enough work to be analysable. `imbalance_ratio` is **not** required (a balanced too-small shape still qualifies). Common cause: `blockDim` too large for the problem shape (`(m × n) / (baseM × baseN) < blockDim`). Fix the launch or the shape; do not chase bound types. Without this check, the later steps will all "fire" on noise.
+3. **SIMD VF code-shape check** ([aiv §6](performance-issues-aiv.md)) — if `simd_vf_metrics` block is non-empty (kernel uses `__simd_vf__` + `asc_vf_call`), check §6.1–§6.3 **BEFORE** pipe-bound diagnosis (steps 4+). Code-shape issues (fragmentation, serial dependency) often manifest as SCALAR/MTE2 overhead in pipe utilization — fixing the structure first may eliminate the pipe-bound symptom. If §6 triggers, apply the fix and re-profile before continuing to step 4.
+4. **`dcache_refill_count`** ([aic §6.1](performance-issues-aic.md)) — if > 0, register spill is reaching GM; fix before other pipeline work.
+5. **Wasted transports** ([aic §5](performance-issues-aic.md)) — scan `bandwidth` for redundant paths (e.g. `L0C_TO_OUT` + `MTE2_OUT_TO_UB` for the same payload). Or, if `bandwidth` is absent, look for `AIVx_MTE2.mean > 0` in a kernel that should have no AIV-side GM input.
+6. **`dominant_pipeline` + utilization** — identify the primary bound type using the table in §2 above.
+7. **`pipeline_overlap`** for that bound's key pair — determine if parallelism is working (double buffer, inter-core pipeline). When overlap is in `0.30–0.60` and double buffer is already in the code, the next-step optimization is usually a *scheduling* change (e.g. SWAT tile order for MTE2 — see aic §2.2), not more buffers.
+8. **`bandwidth` for the bound's transport** — check DMA efficiency if the pipeline is still bound after overlap is good.
+
+After each fix, re-run `npusim record --gen-report` and verify `kernel_total_clocks` decreased. If it didn't, your diagnosis was wrong — back up to the earliest step that still applies.
+
+> **Shape-dependent effect size**: the magnitude of any fix's win on `kernel_total_clocks` is a function of the kernel shape (`m`, `n`, `k`, batch dimensions, loop counts), not just the fix itself. Two shapes where the *same* bottleneck dominates can show very different speedups for the same fix: small shapes amortize startup overhead poorly, large shapes spread per-iteration savings across more iterations. A small measured win (e.g. ~5%) does not invalidate the fix — it may just mean the test shape under-represents production. Re-verify direction (which metric moved which way) rather than magnitude. If a fix's direction is wrong, the diagnosis was wrong; if direction is right but magnitude is small, try a more representative shape before discarding the fix.
+
+> **Optimizations are not always additive — an earlier one can block a later one.** When a fix doesn't improve (or regresses) `kernel_total_clocks`, the cause may not be the fix itself but a **prior** optimization that conflicts with it — and not necessarily the immediately preceding one; it can be any earlier step. To find it: identify what the new fix needs to **remove or restructure** to pay off (a buffer, a data layout/format, a loop or scheduling structure), then trace **which earlier step introduced that thing**. That step is the blocker, even if it sped the kernel up in isolation — a weaker optimization is often **superseded** by a stronger one that targets the same region more fundamentally (e.g. a small algebraic/scalar tweak vs. a full register-resident rewrite). Decision: **revert the conflicting earlier step** and re-derive the later fix from the clean base, rather than stacking the new fix on top of the old structure; then re-profile. This is only practical if each optimization is kept as a **separate, revertible revision** (commit / file) — so do that, and treat "roll back step M, re-apply step N" as a normal move, not a rewrite.
+
+---
+
+## Derived Metrics
+
+Cross-section calculations that combine fields from multiple `summary.json` sections for deeper diagnosis:
+
+| Derived metric | Formula | Diagnostic use |
+|----------------|---------|----------------|
+| Absolute busy time | `pipe_utilization.pipeline_util_summary.<pipe>.mean × kernel_info.kernel_total_clocks` | Converts utilization ratio to absolute ticks. Use to compare pipe busy time across kernels with different `kernel_total_clocks`. |
+| Effective compute ratio | `<compute_pipe>.mean / top_level_diagnosis.dominant_pipeline_util` | If dominant pipe is MTE2 but `AIC_CUBE.mean / dominant_pipeline_util` is high, compute is being diluted by data movement. |
+| Double-buffer vs source code | `pipeline_overlap.<pair>` compared with `bufNum` in kernel source | overlap < 0.30 **and** `bufNum >= 2` in source → not a buffer count issue, it's a scheduling/tile-order issue (e.g., SWAT needed). overlap < 0.30 **and** `bufNum == 1` → enable double buffer. |
+| Bandwidth vs pipeline utilization | `bandwidth.<path>.bandwidth_utilization` vs `pipe_utilization.<pipe>.mean` | bandwidth saturated (< 0.70) but pipe idle → bandwidth-bound; pipe busy (> 0.50) but bandwidth low → compute-bound (data movement not the bottleneck). |
+| Per-core spread | `max(pipe_utilization.<pipe>.per_core) - min(...)` | Quick imbalance signal without reading `aicore_utilization.json`. If spread > 0.15, locate the outlier core. |

package/assets/ops-direct-invoke/skills/ops-simulator/references/pipeline-bubble-analysis.md

@@ -0,0 +1,269 @@
+# 流水线空泡分析（Simulator Trace）
+
+读取 simulator 产出的 `trace_core*.json`（Chrome Trace Format），按以下标准自主判定流水空泡类型和根因。
+
+**定位**：trace 分析回答"主 pipeline（VECTOR/CUBE）为什么 idle"（WHY）。
+
+**使用时机**：
+- 无 NPU 硬件时，直接通过仿真定位性能瓶颈
+- 有 NPU 时，下沉到 trace 查看具体等待原因
+
+---
+
+## 脚本辅助预分析
+
+如需批量处理多核 trace，可运行 `scripts/trace_bubble_analyzer.py` 获取预分类报告：
+
+```bash
+# 分析单个 trace
+python3 {skill_path}/scripts/trace_bubble_analyzer.py report/trace_core0.json
+
+# 分析 simulator 输出目录（自动发现所有核）
+python3 {skill_path}/scripts/trace_bubble_analyzer.py ./npusim_Ascend950_*/report/
+
+# 输出 JSON 供进一步分析
+python3 {skill_path}/scripts/trace_bubble_analyzer.py ./npusim_Ascend950_*/report/ --json -o bubble_report.json
+
+```
+---
+
+## Pipeline 识别
+
+读取 trace 时，从 `traceEvents` 中的 metadata 事件（`ph="M"`, `name="process_name"`）自动发现 PID 与 pipeline 的映射关系。
+
+**需要注意的格式差异**：
+
+| 情况 | 说明 |
+|------|------|
+| npusim VECTOR 细分 | npusim 将 VECTOR 拆分为 RVECSU/RVECEX/RVECLD/RVECST/RVECLP，分析时统一归并为 VECTOR |
+| FIXPIPE 别名 | npusim 中字段名为 `FIXP`，与 `FIXPIPE` 等价 |
+| 指令缓存未命中 | msprof 中为 `CACHEMISS`，npusim 中为 `ICACHELOAD` |
+
+---
+
+## 空泡分类体系
+
+空泡 = 主 pipeline（veccore: VECTOR / cubecore: CUBE）的 duration 事件之间的 idle 时间（`ph="X"` 事件，gap = next.ts - current.end_ts）。
+
+对每个空泡查看**同一时间段内其他 pipeline 的状态**，按以下标准分类。
+
+### Flow 事件辅助因果归因
+
+除 `ph="X"` 事件外，trace 中还包含 Flow 事件（`ph="s"` start / `ph="f"` finish），表示管线间的 flag 依赖关系。每对 s/f 通过 `id` 字段配对，`name` 描述阻塞原因（如 `"MTE1 awaiting CUBE flag, pipe is blocked."`）。
+
+**使用方式**：在空泡窗口内查找 Flow 事件，直接定位"谁等谁的 flag"：
+- `name` 包含 `awaiting <PIPE> flag` → 当前管线在等待 `<PIPE>` 完成后才能继续
+- 配合 `pid`（管线号）和 `tid`（slot 号）定位具体阻塞源
+
+> Flow 事件比"查看同期 busy pipeline"更精确——它直接记录了 flag 因果链，而非间接推断。
+
+### 一级分类
+
+| 类别 | 含义 | 可优化 | 典型根因 |
+|------|------|--------|---------|
+| **NORMAL** | 正常发射间距 | No | 指令依赖或硬件发射限制 |
+| **STRUCTURAL** | 流水线结构性开销 | No | drain/barrier/icache miss/首尾 tile 填充排空 |
+| **DATA_STALL** | 数据搬运等待 | ★★ | MTE2/MTE3 未完成，VEC/CUBE 在等待数据 |
+| **SCALAR_OVERHEAD** | 标量计算/加载阻塞 | ★ | SCALARLDST 参数加载或地址计算阻塞主 pipeline |
+| **RESOURCE_CONTENTION** | 资源竞争 | △ | MTE2+MTE3 总线竞争、UB bank conflict |
+| **CROSS_CORE** | 跨核不均衡 | ★ | 各核工作量不均，部分核提前完成等待 |
+| **CUBE_VECTOR** | Cube-Vector 协同 | ★ | MatMul 类算子中 Cube 和 Vector 流水不匹配 |
+
+### 二级分类判定规则
+
+**四档过滤（按 gap 大小）**：
+
+| 档位 | gap 范围 | 初步方向 | 说明 |
+|------|----------|---------|------|
+| **Tier A** | < 1 ps | **NORMAL** | 正常发射间距，无需深入分析 |
+| **Tier B** | 1 ~ 30 ps | **STRUCTURAL** | 检查是否 drain/barrier |
+| **Tier C** | 30 ~ 500 ps | **SCALAR / DATA** | 检查 scalar 开销或数据搬运等待 |
+| **Tier D** | > 500 ps | **SYNC / COLD_START** | 检查显式同步、冷启动、尾排空 |
+
+**判定方法**：
+1. 先按 gap 大小确定档位（上表）
+2. 再检查该空泡窗口内其他 pipeline 的活跃状态，匹配下表子类型
+3. VecCore 与 CubeCore 使用不同归因优先级（CubeCore 额外检查 FIXPIPE）
+
+**"同期覆盖率"**：某 pipeline 在空泡窗口内的活跃时长 / 窗口总时长。覆盖率只在 Tier C 和 Tier D 使用：
+- Tier C（30~500ps）：覆盖率 **> 30%** 即判定为"busy"
+- Tier D（>500ps）：覆盖率 **> 50%** 即判定为"busy"
+- Tier A/B 不检查覆盖率（A 直接 NORMAL，B 直接查 drain/barrier）
+
+#### NORMAL
+
+| 子类型 | 含义 | 判定标准 | 优化方向 |
+|--------|------|---------|---------|
+| `N_ISSUE_GAP` | 正常发射间距 | gap < 1.0 ps；或 1-30ps 但前指令非 drain 类 | 无需优化 |
+
+#### STRUCTURAL
+
+| 子类型 | 含义 | 判定标准 | 优化方向 |
+|--------|------|---------|---------|
+| `S_DRAIN` | 流水线排空 | **Tier B（1~30ps）**：前指令为 VNCHWCONV 等 drain 类；**Tier C（30~500ps）**：所有 pipeline 均 idle；**Tier D（>500ps）**：不属于其他任何子类型时兜底 | 无需优化 |
+| `S_BARRIER` | PipeBarrier 同步 | 1-30ps 且前指令为 PipeBarrier / BAR | 无需优化 |
+| `S_COLD_START` | 首 tile 流水线填充 | gap ≥ 500ps 且为首 tile（iteration_index == 0） | 减少核数、缩小 TilingData |
+| `S_TAIL_DRAIN` | 尾 tile 流水线排空 | gap ≥ 500ps 且为尾 tile（iteration_index == 末位） | 减少核数、缩小 TilingData |
+| `S_ICACHE_MISS` | 指令缓存未命中 | 同期 CACHEMISS 活跃（任意 Tier） | 减少代码量、减少条件分支 |
+| `S_FLOWCTRL` | 流控指令开销 | 同期 FLOWCTRL 活跃（Tier C，30~500ps） | 无需优化 |
+
+#### DATA_STALL
+
+| 子类型 | 含义 | 判定标准 | 优化方向 |
+|--------|------|---------|---------|
+| `D_MTE2_WAIT` | 显式等待 MTE2 数据加载 | gap ≥ 500ps 且存在 WAIT_FLAG 声明等待 MTE2 | 使能双缓冲，重叠 MTE2 与计算 |
+| `D_MTE2_IMPLICIT` | 隐式等待 MTE2 | **Tier C（30~500ps）**：MTE2 覆盖率 > 30%；**Tier D（>500ps）**：无 WAIT_FLAG 但 MTE2 覆盖率 > 50% | 使能双缓冲，重叠 MTE2 与计算 |
+| `D_MTE3_WAIT` | 显式等待 MTE3 写回 | gap ≥ 500ps 且存在 WAIT_FLAG 声明等待 MTE3 | 使能双缓冲，重叠 MTE3 与计算 |
+| `D_MTE3_IMPLICIT` | 隐式等待 MTE3 | **Tier C（30~500ps）**：MTE3 覆盖率 > 30%；**Tier D（>500ps）**：无 WAIT_FLAG 但 MTE3 覆盖率 > 50% | 使能双缓冲，重叠 MTE3 与计算 |
+| `D_MTE2_UNDERSIZE` | MTE2 搬运粒度过小 | 单次搬运量 < 16KB 或 MTE2 事件数/tile > 20 | 增大 tile、向量化搬运、512B 对齐 |
+| `D_MTE3_UNDERSIZE` | MTE3 搬运粒度过小 | 同上，针对 MTE3 通道 | 增大 tile、向量化搬运 |
+| `D_NO_OVERLAP` | 双缓冲未生效 | overlap_pct < 5%；或 Tier D（>500ps）无 WAIT_FLAG 且不属于其他任何子类型 | 检查 bufNum=2、EnQue/DeQue 配对 |
+| `D_PARTIAL_OVERLAP` | 双缓冲部分生效 | overlap_pct 5%-30% | 调整 tile 大小或 UB 分区 |
+
+#### SCALAR_OVERHEAD
+
+| 子类型 | 含义 | 判定标准 | 优化方向 |
+|--------|------|---------|---------|
+| `SC_LDST_BLOCK` | 标量参数加载阻塞 | SCALARLDST 覆盖率 > 30%（Tier C，30~500ps）；或 WAIT_FLAG 等待 SCALARLDST | 参数预取、缩小 TilingData |
+| `SC_COMPUTE_BLOCK` | 标量地址计算阻塞 | SCALAR 覆盖率 > 30%（Tier C，30~500ps）；或 WAIT_FLAG 等待 SCALAR | 简化地址计算、预计算偏移、缩小 TilingData |
+| `SC_TILING_COMPLEX` | 标量 tiling 逻辑复杂 | scalar 事件密集且含多层循环/条件分支 | 简化控制流、移出不变量到 Host |
+
+#### RESOURCE_CONTENTION
+
+| 子类型 | 含义 | 判定标准 | 优化方向 |
+|--------|------|---------|---------|
+| `R_UB_PRESSURE` | UB bank conflict | bank conflict 占比 > 5%（需结合 ResourceConflictRatio.csv） | 调整 UB 地址、添加 padding |
+| `R_ICACHE_THRASH` | 指令缓存抖动 | 代码段过大或频繁跳转导致 icache 未命中率高 | 减少代码量、减少条件分支 |
+| `R_BUS_CONTENTION` | MTE2+MTE3 总线竞争 | 两通道同时高覆盖率且 gap 增大 | 错开搬运时序 |
+
+#### CROSS_CORE
+
+| 子类型 | 含义 | 判定标准 | 优化方向 |
+|--------|------|---------|---------|
+| `X_TILING_IMBALANCE` | 核间 tiling 切分不均衡 | imbalance_ratio = max_time / min_time > 1.3 | 调整 tiling、均匀分配数据 |
+| `X_TAIL_CORE` | 尾核等待 | 某核尾 tile 空泡显著高于其他核 | 均匀分配尾块、调整 Block Dim |
+| `X_SYNC_BARRIER` | 跨核同步屏障等待 | 多核在相近时间点同时出现大范围 idle | 减少同步点、异步迭代 |
+
+#### CUBE_VECTOR
+
+| 子类型 | 含义 | 判定标准 | 优化方向 |
+|--------|------|---------|---------|
+| `CV_CUBE_WAIT` | Vector 等待 Cube 完成 | AIV 空闲时 AIC 仍在计算（需同时分析 AIC/AIV trace） | 调整 AIC:AIV 比例 |
+| `CV_VECTOR_WAIT` | Cube 等待 Vector 完成 | AIC 空闲时 AIC 仍在计算 | 调整 AIC:AIV 比例 |
+| `CV_HANDOFF` | FIXPIPE 格式转换阻塞 | FIXPIPE 覆盖率 > 30%（Tier C，30~500ps）或 > 50%（Tier D，>500ps）；或 WAIT_FLAG 等待 FIXPIPE | 增加 workspace 份数 |
+
+> **注**：> - CROSS_CORE 和 CUBE_VECTOR 中的部分子类型需多核 trace 对比或额外 CSV 数据，脚本无法自动判定，需自主计算
+> - RESOURCE_CONTENTION 类（UB bank conflict、icache thrash、bus contention）需结合额外性能计数器或 ResourceConflictRatio.csv，脚本无法直接判定
+> - DMA 搬运效率（undersize）需统计单次搬运量和事件密度，脚本未实现，可直接从 trace 事件计算
+
+---
+
+## 关键阈值
+
+判定时使用以下阈值：
+
+### 空泡大小快速过滤
+
+参见上文"四档过滤"表格。快速记忆：
+
+| 档位 | gap | 一句话 |
+|------|-----|--------|
+| Tier A | < 1 ps | 太小，忽略 |
+| Tier B | 1~30 ps | 看前面是不是 drain/barrier |
+| Tier C | 30~500 ps | 看谁 busy（scalar/data） |
+| Tier D | > 500 ps | 看同步/冷启动/尾排空 |
+
+> 以上仅为快速过滤，最终分类仍需查归因树表格匹配。
+
+### 跨核不均衡
+
+| 指标 | 均衡 | 轻度不均衡 | 严重不均衡 |
+|------|------|-----------|-----------|
+| `imbalance_ratio = max_time / min_time` | <= 1.3 | 1.3-2.0 | > 2.0 |
+
+> 从各 core 的 trace 统计 VECTOR/CUBE 总活跃时间后计算。
+
+### 双缓冲生效判定
+
+| 重叠比例 | 状态 | 对应子类型 |
+|---------|------|-----------|
+| `overlap_pct < 5%` | 未生效 | `D_NO_OVERLAP` |
+| `overlap_pct 5-30%` | 部分生效 | `D_PARTIAL_OVERLAP` |
+| `overlap_pct > 30%` | 效果良好 | — |
+
+> `overlap_pct = intersect(MTE2_duration, VECTOR_duration) / union(MTE2_duration, VECTOR_duration)`，按单个 tile 计算。
+
+### DMA 搬运效率
+
+| 指标 | 低效 | 正常 |
+|------|------|------|
+| 单次搬运量 | < 16KB | >= 16KB |
+| MTE2 事件数/tile | > 20 | <= 20 |
+
+> 低效 → `D_MTE2_UNDERSIZE` / `D_MTE3_UNDERSIZE`。
+
+### 周期性模式
+
+| 模式 | 判定标准 | 含义 |
+|------|---------|------|
+| **periodic** | 各 tile 的空泡在时间轴上位置对齐（差异 < 5% tile 周期） | 系统性问题，优化可全局消除 |
+| **sporadic** | 空泡位置随机分布 | 偶发，非主要瓶颈 |
+| **cold_start_dominant** | 首 tile 空泡占总空泡 > 30% | 首 tile 填充开销大 |
+| **tail_dominant** | 尾 tile 空泡占总空泡 > 30% | 尾块处理逻辑有问题 |
+
+---
+
+## 优化可行性约束
+
+提出优化方案前，自主验证以下硬件约束：
+
+### 双缓冲可行性
+
+| 约束 | 检查方式 |
+|------|---------|
+| UB 容量 | `2 * tile_size * sizeof(dtype) * pipe_count <= UB_total` |
+| 对齐 | 所有 buffer 起始地址为 32B 整数倍 |
+
+### 增大 Tile 可行性
+
+| 约束 | 检查方式 |
+|------|---------|
+| UB 容量 | `tile_size * sizeof(dtype) * pipe_count <= UB_per_buffer`（考虑双缓冲后） |
+| 负载均衡 | 增大后尾块不能过大（`tail_elements / tile_elements < 0.3`） |
+
+---
+
+## 分析报告输出格式
+
+完成 trace 分析后，输出以下关键结论（控制在 5-10 行内，结论先行）：
+
+### 1. 总体评估
+
+| 项 | 输出 |
+|----|------|
+| 是否有空泡 | 是 / 否（空泡数 > 0 即判定为"是"） |
+| 空泡密度 | 空泡总时长 / core 总运行时长（百分比） |
+| 主瓶颈类别 | NORMAL / STRUCTURAL / DATA_STALL / SCALAR_OVERHEAD / CUBE_VECTOR 中占比最高者 |
+| 可优化比例 | 可优化子类型空泡时长 / 总空泡时长（百分比） |
+
+### 2. Top 3 关键空泡
+
+按空泡时长（gap_us）从大到小排序，取前 3 个：
+
+```
+#1 [子类型] gap=XXX us | 根因：XXX | 优化：XXX（如可优化）
+#2 [子类型] gap=XXX us | 根因：XXX | 优化：XXX
+#3 [子类型] gap=XXX us | 根因：XXX | 优化：XXX
+```
+
+**判定"关键"的标准**：
+- 优先选 gap > 500ps（Tier D）的空泡
+- 其次选可优化（optimizable=True）的空泡
+- 若前两者不足 3 个，再补 STRUCTURAL 类中最大的
+
+### 3. 行动建议
+
+一句话总结：
+- **可优化为主** → "建议优化 XXX（如使能双缓冲/简化标量计算）"
+- **STRUCTURAL 为主** → "空泡以结构性开销为主，优化空间有限，建议检查核数/TilingData"
+- **无显著空泡** → "空泡密度低，性能瓶颈不在 pipeline idle，建议排查其他因素"