@kernaut/kernaut-resources 0.1.17-beta.1 → 0.1.18

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/compute/parallel-workspace/dual-aiv-global-index-pitfall.md

@@ -1,36 +0,0 @@
----
-id: pitfall-ascendc-dual-aiv-global-workspace-index
-knowledge_id: knowledge-lane-split-preserve-global-workspace-index
-knowledge_id_source: agent-semantic-link
-knowledge_scope: conditional-general
-verified_operators: [na3d_varlen_forward]
-condition_ids: [condition-a2f690bde5822a34]
-title: "AscendC 双 AIV：拆分任务时不能把共享 workspace 索引局部化"
-type: pitfall
-vendor: ascend
-architectures: [ascend910b]
-soc: [ascend910b2c]
-languages: [ascendc]
-confidence: inferred
-evidence_level: inferred
-cann_version: "9.0.0"
-scope: "多个 AIV 拆分 gather、scatter 或 sentinel 写入，但仍共享全局 workspace 布局的实现"
-tags: [ascendc, ai-core]
-related:
-  - technique-ascendc-dual-aiv-physical-group-mapping
-  - pitfall-ascend-na3d-lane-local-union-row
----
-
-# AscendC 双 AIV：拆分任务时不能把共享 workspace 索引局部化
-
-## 失败模式
-
-多个 AIV 分担不同 lane 或 query 集合时，如果每个 AIV 都从 `unionRow = 0` 开始写共享 workspace，就会把局部行号误当成全局行号。不同 AIV 的 gather、sentinel 或后续归约可能因此覆盖或错读数据。
-
-## 正确边界
-
-可以按 lane 或 subblock 拆分工作，但共享 workspace 的地址必须由全局行号、物理组和既定布局共同计算。空 lane、尾行和同步标志也要有明确协议，不能只验证有数据的 lane。
-
-## 证据边界
-
-当前反例来自 `na3d_varlen_forward` 的双 AIV gather 路径；它证明局部化共享索引会破坏该类布局，不等于所有 AIV 拆分实现都必须使用同一套索引公式。其他算子需要按自己的 workspace 布局复测。

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/compute/parallel-workspace/dual-aiv-physical-group-mapping.md

@@ -1,55 +0,0 @@
----
-id: technique-ascendc-dual-aiv-physical-group-mapping
-knowledge_id: knowledge-dual-aiv-switch-requires-index-remap
-knowledge_id_source: agent-semantic-link
-knowledge_scope: conditional-general
-verified_operators: [na3d_varlen_forward]
-condition_ids: [condition-211a6f45b7711a9d, condition-59c23087fc090221]
-title: "AscendC 双 AIV：按物理组重映射 workspace 与同步协议"
-type: technique
-vendor: ascend
-architectures: [ascend910b]
-soc: [ascend910b2c]
-languages: [ascendc]
-confidence: source-reported
-evidence_level: measured
-cann_version: "9.0.0"
-reproducibility: snippet
-prerequisites: []
-sources: []
-scope: "从 AIC:AIV=1:1 切换到 1:2，且两个 subblock 共享 workspace 或 CrossCore 同步标志的实现"
-tags: [ascendc, ai-core]
-related:
-  - pitfall-ascend-na3d-dual-aiv-without-remap
-  - pitfall-ascend-na3d-lane-local-union-row
-  - exp-ascend-na3d-dual-aiv-query-split
-  - exp-ascend-na3d-dual-aiv-row-group-2
----
-
-# AscendC 双 AIV：按物理组重映射 workspace 与同步协议
-
-## 核心做法
-
-从单 AIV 改成双 AIV 时，先用物理组编号建立生产者、消费者和 workspace 的共同地址映射，再用 subblock 编号拆分互不重叠的工作集合。同步标志也必须跟随物理组和实际消费者关系重新布局。
-
-## 为什么不是简单加并行度
-
-只修改 kernel 类型或 AIV 数量，会改变 block 与 subblock 的编号关系；继续使用单 AIV 的逻辑索引可能让两个消费者访问错误的 workspace、覆盖彼此的数据，或等待错误的同步标志。
-
-## 证据边界
-
-当前证据来自 `na3d_varlen_forward`，在 Ascend 910B2C、AscendC 和固定 NA3D workspace 协议下观察到。该机制适合迁移到具有相同物理组共享和跨核同步结构的其他算子，但尚未由第二个算子独立验证，因此页面不是跨算子 `verified` 结论。
-
-## 应用前检查
-
-- 明确 block、subblock、物理组和全局行号之间的映射。
-- 检查每个 workspace 槽位的生产者、消费者和生命周期。
-- 检查空 lane 或尾块是否仍参与一致的同步协议。
-- 对原算子和新并行模式分别做正确性与性能验证。
-
-```cpp
-uint32_t physicalGroup = asc_get_block_idx();
-uint32_t subblock = asc_get_sub_block_id();
-uint32_t workspaceRow = physicalGroup * rowsPerGroup + globalRow;
-uint32_t syncSlot = physicalGroup * syncSlotsPerGroup + consumerId;
-```

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/compute/quant-matmul-output/pitfalls.md

@@ -1,110 +0,0 @@
----
-id: pitfall-ascendc-quant-matmul-output
-title: "int8 Matmul Cannot Emit bf16 Through fixpipe — and the half Workspace Has Two Separate Traps"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-cann_version: '9.0.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  int8 inputs, so L0C is int32. With float L0C the F322BF16 path exists and none of
-  this applies. The 2^k rescale below is exact only because the factor is a power of
-  two; a general scale factor reintroduces rounding.
-tags:
-- ascendc
-- cube-unit
-- l0c
-- quantization
-hardware_features:
-- cube-unit
-- l0c
-kernel_types:
-- quantization
-related:
-- pitfall-ascendc-int8-cast-no-clamp
-aliases:
-- "int32 L0C 出不了 bf16"
-- "half 中间量 量程 相消"
-- "fixpipe 随路量化"
----
-
-## P1. There is no int8 → bf16 path through fixpipe
-
-int8 inputs mean L0C holds int32, and fixpipe's inline quantization offers only
-`DEQF16` / `VDEQF16`, both of which emit fp16. The `F322BF16` mode in
-`copy_matrix_cc_to_gm` **requires L0C to be float**, so the int8 path cannot reach it.
-
-bf16 output therefore has to be produced in two stages, and the two ways of doing
-that fail differently:
-
-| Route | Cost | Traps |
-|---|---|---|
-| **half workspace, half-fused** (cube emits half, post does per-token scale + cast) | GM round-trip 4+4+2 → **2+2+2** bytes/element — fast | both P2 and P3 below |
-| **int32 exact** (cube emits int32, post entirely in fp32) | slower | neither |
-
-## P2. Range: `mm·scale` saturates at 65504
-
-half is an 11-bit mantissa **and** a 65504 ceiling, and the ceiling is the expensive
-half. Every case in one held-out set failed here while all 20 cases that were
-visible passed — the visible set happened to contain no K/scale combination that
-reached the ceiling.
-
-> Passing every case you can see is not evidence that the range is safe. It is
-> evidence that you have not sampled the range.
-
-## P3. Cancellation: a different failure with a different signature
-
-With a post-scale float bias, `out = mm·scale + bias`, the absolute error of
-`round_half(mm·scale)` swamps near-zero elements during cancellation — measured
-MARE 0.9997 on one case, 12 of 13 small-magnitude values judged wrong.
-
-**Tell them apart from the raw accuracy report, at zero cost:**
-
-```
-max_diff ≈ 65504 · MARE/(1−MARE)        → fp16 saturation; golden = 65504 + max_diff
-small_value_passed and cancel_passed all true, normal_passed false
-                                        → nothing to do with cancellation
-```
-
-Twenty cases satisfied the first identity individually, ratios all 1.00 across three
-orders of magnitude. **The two diagnoses must be kept apart** — the first analysis
-attributed the held-out failures to cancellation, and that was wrong.
-
-## P4. The cheap fix for range — you do not have to fall back to the exact route
-
-Scaling by a power of two is bit-exact in floating point. Have the pack kernel sweep
-the scales once for `max|scale|`, take
-
-```
-k = max(0, ceil(log2(127² · K · max|scale| / 32768)))
-```
-
-feed `scale · 2^-k` into fixpipe, write `2^k` into the workspace, and multiply it
-back in post. The GM round-trip stays 2+2+2. Measured: MERE bit-identical to before
-on the visible cases, and the range probe went from 6/7 FAIL to 7/7 PASS.
-
-```cpp
-// pack kernel, device side — host-side scale reads need a D2H copy, which
-// stalls the on-device profiler.
-ReduceMax(maxScaleUb, scaleUb, workUb, n);
-float k = max(0.0f, ceil(log2(127.0f * 127.0f * K * maxScale / 32768.0f)));
-Muls(scaleQuantUb, scaleUb, exp2f(-k));     // into fixpipe
-shiftGm.SetValue(0, exp2f(k));              // multiplied back in post
-```
-
-> ⛔ **One global `k`, never per channel.** With a per-channel `k` the quant vector
-> inside fixpipe and the coefficients in post no longer line up, and a subset of
-> elements comes out off by exactly `2^(k span)` — measured MARE ≈7.0, i.e. 8×.
-> **How to tell:** hard-code the shift to a constant and rerun. If everything passes
-> immediately, the mechanism is right and the defect is in the per-channel indexing.
-
-> ⛔ **Never let a scratch pointer fall back to an input pointer when "unused".**
-> Pointing the reciprocal buffer at the input `scale` array in the direct path made
-> pack write 1.0f into the caller's scales. Input tensors are reused across warmup
-> and repeat, so this only surfaced on the second invocation.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/compute/reduction-cost/overview.md

@@ -1,81 +0,0 @@
----
-id: technique-ascendc-reduction-cost-overview
-title: "What Actually Costs Time in an Ascend C Reduction"
-type: technique
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-cann_version: '9.0.0'
-evidence_level: measured
-confidence: experimental
-reproducibility: snippet
-scope: >-
-  DAV_2201 vector unit. Every number below was bought with one build-and-measure
-  round on a reduction-shaped operator; the ordering transfers, the absolute cycle
-  counts carry that kernel's pipeline conditions.
-tags:
-- ascendc
-- ai-core
-- vector-unit
-- reduction
-hardware_features:
-- ai-core
-- vector-unit
-kernel_types:
-- reduction
-techniques: []
-prerequisites:
-- hw-ascend910b2c
-related:
-- pitfall-ascendc-reduce-max-calindex-cost
-- pitfall-ascendc-whole-reduce-sum-cost
-- technique-ascendc-reduce-data-block
-sources:
-- exp-ascend910b2c-reduction-and-broadcast-costs
-source:
-- path: sources/experience/ascend-campaign/ascend910b2c-reduction-and-broadcast-costs.md
-  anchor: Per-construct costs, measured by ablation
-aliases:
-- "归约类算子 什么费时间"
-- "归约耗时构成"
-- "重写归约之前先读"
-- "指令条数定价"
----
-
-## Read this before rewriting a reduction
-
-The cost of a reduction on this part is **not** proportional to the number of
-elements. It is dominated by how many reduction *instructions* are issued and which
-one is used. Three sound-sounding rewrites were measured and rejected because they
-optimized the element count while leaving the instruction count alone.
-
-| Construct | Results per repeat | Cost | Page |
-|---|---:|---|---|
-| `ReduceMax(calIndex)` | 1, **per row** | ≈1 element/cycle — 64× off vector peak | [pitfall](./pitfalls.md) |
-| `WholeReduceSum` (vcadd) | 1 | ≈10.5 cycle/repeat | [pitfall](./whole-reduce-sum-cost.md) |
-| `ReduceDataBlock` (vcgmin/vcgmax) | **8**, one per 32 B block | the cheap one | [technique](./reduce-data-block.md) |
-| any vector instruction | — | ≈40 cycle, near-independent of element count | — |
-
-## The measurement that costs nothing
-
-You do not need to change the algorithm to price a reduction. Change only its
-`count` and rerun:
-
-```cpp
-// count 511 -> 64, everything else identical
-constexpr uint32_t kProbeCount = 64;      // was 511
-for (uint32_t row = 0; row < rows; ++row) {
-    ReduceMax<float>(dst[row], src[row * stride], work, kProbeCount, true);
-}
-```
-
-One case went **59.6 µs → 14.9 µs**. The difference is what that reduction was
-costing. This works because the reduction is the only thing that moved.
-
-> ⚠️ Its cost is **non-linear in count**: ≈450 cycle/row at 511, ≈330 at 2048. So
-> "fold first to shrink the count, then call it" is a losing trade — you pay for the
-> fold and land in a worse part of the curve.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/compute/reduction-cost/pitfalls.md

@@ -1,65 +0,0 @@
----
-id: pitfall-ascendc-reduce-max-calindex-cost
-title: "ReduceMax(calIndex) Runs at ~1 Element per Cycle — 64× Off Vector Peak"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-cann_version: '9.0.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  The index-returning form on DAV_2201. ReduceMax without calIndex is a different
-  instruction and is not covered by this reading. The non-linearity in count was
-  observed at 511 and 2048; the shape of the curve between and beyond was not mapped.
-tags:
-- ascendc
-- ai-core
-- vector-unit
-- reduction
-hardware_features:
-- ai-core
-- vector-unit
-kernel_types:
-- reduction
-related:
-- technique-ascendc-reduction-cost-overview
-- api-ascendc-reduce-repeat
-aliases:
-- "ReduceMax calIndex 很慢"
-- "归约 每行一次"
-- "折叠缩小 count 反而更亏"
----
-
-## P1. It costs about one element per cycle, and it is called once per row
-
-A 511-element int32 row costs about **520 cycle**. The shorter the row, the worse the
-ratio, because the per-call cost does not shrink with it.
-
-**Price it without touching the algorithm:** change `count` from 511 to 64 and rerun.
-One case went **59.6 µs → 14.9 µs**. That difference is what the reduction was
-costing.
-
-## P2. The cost is non-linear in `count`, so "fold first" loses
-
-Measured ≈450 cycle/row at count 511, and ≈**330** at 2048. The cost per row goes
-*down* as the row gets longer.
-
-So the natural-sounding rewrite — fold the data first to shrink `count`, then call
-`ReduceMax` on the smaller row — pays for the fold **and** lands in the more expensive
-part of the curve. It was measured and it loses.
-
-> A construct whose cost is sublinear in its input size inverts the usual instinct.
-> Check the direction of the curve before optimizing the thing you feed it.
-
-## P3. What to use instead
-
-For a per-repeat maximum with indices, `ReduceRepeat` is the underlying `vcmax` and
-returns one result per repeat rather than one per call — see
-[`api-ascendc-reduce-repeat`](../../../api-definitions/ascendc/reduce-repeat.md).
-For a per-segment reduction, `ReduceDataBlock` gives 8 results per repeat — see
-[`technique-ascendc-reduce-data-block`](./reduce-data-block.md).

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/compute/reduction-cost/reduce-data-block.md

@@ -1,76 +0,0 @@
----
-id: technique-ascendc-reduce-data-block
-title: "Segmented Reduction with ReduceDataBlock — 8 Results per Repeat"
-type: technique
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-cann_version: '9.0.0'
-evidence_level: measured
-confidence: experimental
-reproducibility: snippet
-scope: >-
-  half and float only (SupportType<half, float>); int32 has no ReduceDataBlock and
-  must keep the older fold. The two-level shape below assumes segments fit the block
-  granularity - check nSeg against 8 before assuming two levels suffice.
-tags:
-- ascendc
-- ai-core
-- vector-unit
-- reduction
-hardware_features:
-- ai-core
-- vector-unit
-kernel_types:
-- reduction
-techniques: []
-prerequisites:
-- technique-ascendc-reduction-cost-overview
-related:
-- api-ascendc-reduce-data-block-strides
-- api-ascendc-reduce-data-block-nan
-- pitfall-ascendc-whole-reduce-sum-cost
-sources:
-- exp-ascend910b2c-reduction-and-broadcast-costs
-source:
-- path: sources/experience/ascend-campaign/ascend910b2c-reduction-and-broadcast-costs.md
-  anchor: Per-construct costs, measured by ablation
-aliases:
-- "分段归约"
-- "ReduceDataBlock 每 repeat 八个结果"
-- "vcgmin vcgmax"
----
-
-## Per-row and per-segment are different problems
-
-`WholeReduceSum` reduces a whole repeat to **one** result, which is the right shape
-for a per-row reduction and the wrong shape for a per-segment one.
-`ReduceDataBlock<ReduceType::MIN/MAX/SUM>` produces **8 results per repeat**, one per
-32 B block — that is the per-segment primitive.
-
-A segment-minimum fold that was a 6-step `Min` tree (each step touching the whole
-tile) plus a `Gather` transpose plus a per-row fold — about 9 instructions — becomes
-**two**:
-
-```cpp
-// red, sm, xv: LocalTensor<float>;  VL = elements per repeat
-constexpr int32_t VL = 64;
-const uint8_t nSeg = static_cast<uint8_t>(segs);
-// level 1: nSeg repeats, each segment folded to 8 block minima
-ReduceDataBlock<ReduceType::MIN>(red, xv, /*mask=*/VL, nSeg, RPS, 1, 8);
-// level 2: one repeat spans 8 blocks = 8 segments, emitting 8 segment minima, packed
-ReduceDataBlock<ReduceType::MIN>(sm, red, VL, (nSegT + 7) / 8, 1, 1, 8);
-```
-
-## Two things to get right before using it
-
-- **`dstRepStride` is counted in "8 results", not in bytes** — the units differ
-  between `half` and `float`, and getting it wrong is silent. See
-  [`api-ascendc-reduce-data-block-strides`](../../../api-definitions/ascendc/reduce-data-block-strides.md).
-- **NaN propagates bit-exactly**, so a mask that depends on NaN reaching the segment
-  minimum needs no repair pass. See
-  [`api-ascendc-reduce-data-block-nan`](../../../api-definitions/ascendc/reduce-data-block-nan.md).

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/compute/reduction-cost/whole-reduce-sum-cost.md

@@ -1,71 +0,0 @@
----
-id: pitfall-ascendc-whole-reduce-sum-cost
-title: "WholeReduceSum Emits One Result per Repeat at ~10.5 cycle — Two Thirds of a Serial Step"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-cann_version: '9.0.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  Measured on a serially recursive operator where 99% of time is inside the time-step
-  loop, so the per-step figures are the whole story there. On a kernel with real
-  parallelism the same instruction cost applies but its share will be smaller.
-tags:
-- ascendc
-- ai-core
-- vector-unit
-- reduction
-hardware_features:
-- ai-core
-- vector-unit
-kernel_types:
-- reduction
-related:
-- technique-ascendc-reduce-data-block
-- technique-ascendc-reduction-cost-overview
-- pitfall-ascendc-transpose-axpy-recurrence
-aliases:
-- "WholeReduceSum 每 repeat 一个结果"
-- "vcadd 单价"
-- "逐行归约 单价"
----
-
-## P1. One result per repeat is what pins the cost
-
-Write a matrix-vector product as "`Mul` for the products, then one `WholeReduceSum`
-per row" and **every output row costs one vcadd repeat**. Ablation — comment out the
-reduction once, comment out the whole matvec once, fit the slope at T = 10 and 40:
-
-| Component | H = 32 | H = 64 | Reading |
-|---|---:|---:|---|
-| cell update | 0.520 µs | 0.512 µs | **independent of H** ⇒ issue-bound |
-| matvec `Mul` | 0.13 | 0.27 | ≈2 cycle/repeat |
-| **`WholeReduceSum` + `Add`** | 0.49 | **1.56** | **two thirds of the step**, ≈**10.5 cycle/repeat** |
-
-## P2. The replacement: two passes of `ReduceDataBlock`
-
-`ReduceDataBlock<ReduceType::SUM>` (vcgadd) is ≈2 cycle/repeat and emits **8 results
-per repeat**, one per 32 B block. So "one pass folding the products (`rows` repeats,
-8 partials each) plus one pass folding the partials (`rows/8` repeats)" replaces
-`rows` vcadd calls with `rows + rows/8` vcgadd calls. **Measured 2.07× per step.**
-
-> **Any kernel with a per-row or per-output reduction should be checked against this.**
-> It is a different problem from a reduction that carries a vector-to-scalar
-> round-trip: even with no round-trip at all, **the number of output rows pins the
-> repeat count**.
-
-## P3. Two things that make it work
-
-**Chunks narrower than 64 lanes still qualify.** Zero the product buffer once at
-start-up; `Mul` then writes only `[0, klen)` at a fixed row pitch, so the tail lanes
-stay zero and a `mask = 64` block reduction is still correct.
-
-⚠️ **Enlarge products, partials and the cast buffer together.** Enlarging only the
-products writes through the 16 KB cast region — four cases failed accuracy outright
-when that was missed.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/compute/scalar-ub-candidates.md

@@ -1,64 +0,0 @@
----
-id: algo-ascendc-scalar-ub-candidates
-title: AscendC scalar hot paths, UB residency and core shrinking
-type: algorithm
-vendor: ascend
-architectures:
-- ascend910b
-- ascend950
-languages:
-- ascendc
-tags:
-- ascendc
-confidence: source-reported
-evidence_level: inferred
-scope: Selected cannbot notes at ddea090f28ec863e97a65f71ccc9cc9b956e327a; architecture
-  and implementation conditions are stated per section. No local SDK compilation or
-  device validation.
-sources:
-- blog-cannbot-ascendc-notes
-source:
-- path: sources/blogs/cannbot-ascendc-notes.md
-  anchor: ops/ascendc-performance-best-practices/references/common/core_shrink_design.md
-- path: sources/blogs/cannbot-ascendc-notes.md
-  anchor: ops/ascendc-performance-best-practices/references/common/ub_resident_design.md
-- path: sources/blogs/cannbot-ascendc-notes.md
-  anchor: ops/ascendc-performance-best-practices/references/scalar/coding_principles.md
-- path: sources/blogs/cannbot-ascendc-notes.md
-  anchor: ops/ascendc-performance-best-practices/references/scalar/conv_scalar.md
-- path: sources/blogs/cannbot-ascendc-notes.md
-  anchor: ops/ascendc-performance-best-practices/references/scalar/guide.md
-related: []
----
-
-# AscendC scalar hot paths, UB residency and core shrinking
-
-Source-reported constraints and adapted algorithms from the [pinned cannbot snapshot](../../../../sources/blogs/cannbot-ascendc-notes.md). These notes are not an SDK specification or a device validation record. Existing versioned API and measured pages remain authoritative for their stated scope.
-
-## Existing coverage and the added scope
-
-[Constexpr parameters](../../techniques/constexpr-parameters/README.md), [loop-invariant hoisting](../../techniques/loop-invariant-hoisting/README.md) and [core partitioning](../../techniques/vector-core-partition/README.md) already describe the general ideas, mostly through Triton examples. This page adds AscendC compiler/lifetime candidates and a core-count counterexample; it does not replace those definitions.
-
-| Observed scalar cost | Candidate | Evidence to inspect |
-|---|---|---|
-| Dynamic slot indexing or escaped objects block constant propagation | Scalar fields or compile-time slots | Address/branch instructions; preserve event-to-slot identity |
-| First/last iteration tests inside a hot loop | Prologue / steady loop / epilogue | Branch reduction versus code size |
-| Repeated member loads or deep pointer aliases | Local values and a shorter alias chain | Loads, register pressure and spill |
-| Captured state keeps values live too long | Explicit loops and shorter live ranges | Stack traffic and loop latency |
-| Invariant objects constructed repeatedly | Hoist construction when state permits | Confirm construction actually survives compilation |
-
-A runtime `const` is not necessarily a compile-time specialization. Do not specialize on benchmark samples outside the declared domain. Fewer C++ lines do not prove fewer instructions; indiscriminate unrolling can increase code size and live ranges. TPipe overhead is not permission to remove synchronization.
-
-## Resident data versus address reuse
-
-Keeping small repeatedly used parameters in UB saves repeated loads but shrinks streaming tiles. Compare the full live set. Sharing an address between stages is a different optimization: C++ scope exit does not complete an asynchronous consumer. Preserve the existing [WAR/event lifecycle](double-buffer-war/techniques.md).
-
-For suspected structured UB bank conflicts, relative source/destination offsets, pitch and small padding such as 32/256 bytes are experiments, not architecture-independent prescriptions. Use target conflict/stall evidence; do not promote a source's approximate bank-cycle formula into a hardware fact.
-
-## A core-count candidate is not a minimum-work guarantee
-
-For R rows and at most C cores, `used=min(C,max(1,ceil(R/m)))` does not ensure at least m rows per core: R=65 and m=64 select two cores with 33/32 rows.
-
-For a chosen used>0, let q=R//used and r=R%used. Core c owns q+1 rows if c<r, otherwise q, beginning at `c*q+min(c,r)`. Check the resulting work, alignment, tail and launch costs. Empty input has its own path. Keep launch participants and barrier participants consistent when shrinking the active set.
-
-This is workload balancing, not a ban on grid-stride or swizzled schedules. Coverage, storage ownership and actual cross-iteration dependencies determine which schedules are legal.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/compute/tiny-case-fixed-cost/pitfalls.md

@@ -1,96 +0,0 @@
----
-id: pitfall-ascendc-tiny-case-fixed-cost
-title: "On Tiny Cases Almost All of the Kernel Time Is Fixed Cost — Prove It by Regression"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910c
-languages:
-- ascendc
-cann_version: '9.1.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  The slope and the constant below are one epilogue kernel of one Conv2D operator on
-  910C under CANN 9.1.0. They are an instance, not a constant to reuse: the method is
-  to fit your own, and the non-monotonicity test is the part that needs no fitting at
-  all. Note the SoC - the launch-floor page that this one points at was re-measured
-  on 910B2C, and the two were not measured on the same part.
-tags:
-- ascendc
-- ai-core
-hardware_features:
-- ai-core
-kernel_types:
-- elementwise
-related:
-- hw-ascend-kernel-launch-floor
-- pitfall-ascendc-matmul-api-fixed-cost
-- technique-ascendc-double-buffer-war
-sources: []
-aliases:
-- fixed cost
-- fixed overhead
-- tiny case
-- small tensor
-- non-monotonic
-- cost model
-- 固定开销
-- 微型用例
-- 小用例
-- 非单调
-- 回归拟合
----
-
-## Search Keywords
-
-fixed cost, fixed overhead, tiny case, small tensor, per-call constant,
-non-monotonic, least squares, cost model, 固定开销, 微型用例, 小用例, 非单调,
-回归, 成本随字节数.
-
-## The reading
-
-Least-squares fit of `kernel_us ~ a + b * output_elements` across all cases of one
-Conv2D epilogue kernel:
-
-```
-slope           6.75 us per million elements
-37 cases at <= 32K elements   median 2.12 us, of which real data movement 0.028 us
-                              => fixed cost 98.7%
-```
-
-At that size the kernel spends **98.7%** of its time on something that does not
-depend on how much data there is. Retiling, widening the copy and trimming the
-transfer all move the 1.3%.
-
-⚠️ **`2.12 us` is the cost at that size, not a floor.** It was read on 910C and it
-sits inside the band a 910B2C re-measurement gives for the same element counts
-(16 384 elements: 1.45-1.86 us; 65 536 elements: 2.32-3.00 us). The actual floor -
-what a kernel costs when the data is negligible - is **about 1.08 us at 1K elements
-or fewer**, measured across twelve op x dtype combinations with a 1.10x spread; see
-[the tiny-kernel device floor](../../../hardware/kernel-launch-floor.md). Reading a
-size-dependent cost as a floor is how three different numbers came to look like a
-contradiction when they were measuring three different things.
-
-## The cheaper test: non-monotonicity
-
-Fitting a line needs a sweep. Falsifying "the cost tracks the byte count" needs two
-points:
-
-**128 elements took 2.92 us; 1024 elements took 1.86 us.** The smaller case is
-slower. No amount of curve fitting is required to conclude that byte count is not
-the driver.
-
-What is left as the driver is **the number of inner-function invocations times the
-synchronisation round trips each one pays** - which is why the fix for this shape of
-cost is a pipelining change and not a memory change. See
-[hand-written double buffering](../double-buffer-war/techniques.md).
-
-## Why the regression is worth doing anyway
-
-The two-point test tells you the cost is not data-bound. The fit tells you **where
-the crossover is** - above which element count the slope dominates and the fixed cost
-stops being worth attacking. Without that number the same optimisation gets applied
-to cases it cannot help, and the aggregate reading comes back flat.