@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/integer-arithmetic/techniques.md

@@ -1,86 +0,0 @@
----
-id: technique-ascendc-integer-beyond-fp32-window
-title: "Integer Modulo Beyond the fp32 Exact Window — Quotient in Float, Remainder in Int"
-type: technique
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-cann_version: '9.0.0'
-evidence_level: measured
-confidence: experimental
-reproducibility: snippet
-scope: >-
-  Operands up to 2^31 on a unit whose int32 vector surface lacks a divide. The step
-  counts come from Lame's theorem and are exact; the pre-scale factor 2^-20 is tied
-  to fp32's ~3·2^-24 relative error and must be recomputed for any other float type.
-tags:
-- ascendc
-- vector-unit
-hardware_features:
-- vector-unit
-techniques: []
-prerequisites:
-- api-ascendc-int32-vector-availability
-related:
-- api-ascendc-int32-vector-availability
-sources:
-- exp-ascend910b2c-memory-and-arith-techniques
-source:
-- path: sources/experience/ascend-campaign/ascend910b2c-memory-and-arith-techniques.md
-  anchor: Integer arithmetic beyond the fp32 exact window
-aliases:
-- "超出 fp32 精确窗口"
-- "商用浮点 余数用整数"
-- "取模 预缩"
----
-
-## The decomposition
-
-fp32 represents integers exactly only up to 2²⁴, but **a quotient only needs the
-ratio**. So `a mod b` splits into a float quotient and an integer remainder, and the
-pair covers the whole int32 range:
-
-```cpp
-// a, b: LocalTensor<int32_t> inputs;  af, bf, qf: LocalTensor<float> scratch
-// q, qb, r: LocalTensor<int32_t>;  n = element count
-Cast(af, a, RoundMode::CAST_NONE, n);
-Cast(bf, Max(b, 1), RoundMode::CAST_NONE, n);
-Div(qf, af, bf);
-Muls(qf, qf, 1.0f - 0x1p-20f);        // pre-scale: guarantees floor(qf) <= true q
-Cast(q, qf, RoundMode::CAST_FLOOR, n);
-Mul(qb, q, b, n);                     // r = a - q*b, computed in int32, exact
-Sub(r, a, qb, n);
-```
-
-## Three requirements — dropping any one of them makes it wrong
-
-**1. The quotient must be pre-scaled.** Without it `q̂ > q_true` is possible, so
-`q̂·b > a`, the int32 multiply overflows, and the remainder comes out negative.
-Scaling by `2⁻²⁰` makes `q̂ ≤ q_true` unconditional, hence `q̂·b ≤ a` and the
-remainder lands in `[0, a]`.
-
-**2. One division is not enough.** fp32's relative error of ~3·2⁻²⁴ becomes an
-absolute error of ~2400 at a ratio of 2³¹, so after the first pass the ratio can
-still be off by a factor of 2364. The **second** pass runs on a small ratio and its
-quotient is exact; the remainder is then at most one `b` too large, and one
-`min(max(r-b, -1), 0)` fold brings it into `[0, b)`.
-
-**3. Bound the step count with Lamé's theorem — do not probe at runtime.** Euclid on
-`a ≤ 2³¹` is at worst 44 steps; getting from 2³¹ down to 2²⁰ is at worst 16; below
-2²⁰ it is at worst 28. **16 + 28 = 44**, so "16 integer pre-reduction steps followed
-by the existing 28-step fp32 fast path" is provably complete.
-
-## The hole that has to be plugged
-
-Only a lane that **keeps reducing** falls below 2²⁰. A lane where one operand is
-zero, or where the two share a large common factor, **freezes at its original value**
-— possibly still above 2²⁴ — and handing it to the fp32 path rounds it. Measured:
-`gcd(0, 1739738135)` returned `1739738112`.
-
-Add a `ReduceMax ≤ 2²⁰` check at the exit and fall the whole tile back to an exact
-scalar path when it trips. The check is one instruction; the failure it catches is
-silent.

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

@@ -1,68 +0,0 @@
----
-id: pitfall-ascendc-level0-mask-ignored
-title: "The level-0 mask Parameter Is Ignored on DAV_2201"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-cann_version: '9.0.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  level-0 (bitmask) interfaces on DAV_2201. The counted forms are unaffected. The
-  workaround below assumes 16-bit bitwise ops, which is what this part actually has.
-tags:
-- ascendc
-- ai-core
-- vector-unit
-hardware_features:
-- ai-core
-- vector-unit
-related:
-- pitfall-ascendc-bitwise-16bit-lanes
-- api-ascendc-int32-vector-availability
-aliases:
-- "level-0 mask 被忽略"
-- "没有 Xor"
-- "lane 选择"
----
-
-## P1. The mask does nothing, and nothing reports it
-
-```cpp
-// Intent: flip the top bit of the even-numbered 32-bit words only.
-// The mask is ignored; the odd-numbered words are flipped too.
-Adds(t, t, (int32_t)0x80000000, 0x5555555555555555ULL, reps, {1,1,8,8});
-```
-
-This is **not** saturation, which is a different failure. **The fingerprint is clean:**
-comparing int64 values word by word, every same-sign pair is correct and every
-opposite-sign pair is **wrong** — exactly 50%.
-
-**How to separate the two hypotheses:** construct `a = 2³²`, `b = 1` — different high
-words, both non-negative. Under the saturation hypothesis that case should be correct;
-under the ignored-mask hypothesis it is not.
-
-## P2. Consequence: no lane selection may depend on a level-0 mask
-
-An int64 maximum was rewritten as seven full-width instructions using no mask at all:
-
-```cpp
-ShiftRight(sa,a32,31); ShiftRight(sb,b32,31); Compare(mSS,sa,sb,EQ);  // same sign, per word
-Max(mx,a32,b32); Compare(mGE,mx,a32,EQ); Compare(mEQ,a32,b32,EQ);
-// Gs = signed >, corrected to unsigned > when the signs differ
-Gs = mGE & ~mEQ;   Gu = mSS ? Gs : ~Gs;
-sel = Gs[hi] | (mEQ[hi] & Gu[lo]);   M = sel | (sel >> 1);
-Select(y, M, a, b);                  // bitwise mux through a float view
-```
-
-The mask bit arithmetic runs on a `uint16` view — `And` / `Or` / `Not` / `ShiftLeft`
-exist only at 16 bits, see
-[`pitfall-ascendc-bitwise-16bit-lanes`](../bitwise-ops/pitfalls.md) — which is 1/16 of
-the width and negligible.
-
-> **DAV_2201 has no `Xor` at all.** Build it as `(A|B) & ~(A&B)`.

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

@@ -1,96 +0,0 @@
----
-id: pitfall-ascendc-matmul-api-fixed-cost
-title: "The High-Level Matmul API Has a Fixed Cost No Parameter Reaches"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910c
-languages:
-- ascendc
-cann_version: '9.1.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  Measured on tiny cases of one Conv2D operator, where the matmul tile is a single
-  tile and the arithmetic is 0.14 us. The absolute numbers are that kernel's; what
-  transfers is the shape of the cost - a per-invocation constant that the parameter
-  surface does not touch - and the stopping rule that follows from it. On cases large
-  enough for the mac time to dominate, none of this is visible.
-tags:
-- ascendc
-- cube-unit
-- ai-core
-hardware_features:
-- cube-unit
-- ai-core
-kernel_types:
-- gemm
-related:
-- pitfall-ascendc-matmul-knobs-non-improvements
-- pitfall-ascendc-tiny-case-fixed-cost
-- hw-ascend-kernel-launch-floor
-sources: []
-aliases:
-- Matmul API overhead
-- IterateAll cost
-- Init End cost
-- instruction cache miss
-- icache miss
-- Matmul 固定开销
-- 高层 API 没有免费午餐
-- 指令 cache
----
-
-## Search Keywords
-
-Matmul API overhead, IterateAll, Init, End, fixed cost, per-invocation cost,
-instruction cache miss, icache_miss, aic_icache_miss_rate, template code size,
-Matmul 固定开销, 高层 API, 指令 cache, 小用例很慢.
-
-## The reading
-
-On a tiny case, the CANN high-level Matmul API costs:
-
-| component | time |
-|---|---:|
-| `Init` + `End` | **2.0 us** |
-| one tile of `IterateAll` | **3.9 us** |
-| the mac work inside it | **0.14 us** |
-
-The arithmetic is under 3% of what the call costs. This is a per-invocation
-constant, not a function of the tile, which is why shrinking the tile does not
-shrink it - see
-[the parameter knobs that were tried](../measured-non-improvements/matmul-knobs.md).
-
-## The mechanism: the template does not fit in instruction cache
-
-PMU counters for the three kernels of that operator on a tiny case:
-
-| kernel | scalar ratio | mac ratio | icache miss |
-|---|---:|---:|---:|
-| im2col | 42.6% | - | 0 |
-| matmul | 48.5% | **2.4%** | **15.7%** |
-| epilogue | 52.2% | - | 0 |
-
-**On the large cases of the same operator `icache_miss` is 0.0 everywhere.** The
-miss rate is not a property of the Matmul template alone and not a property of the
-case size alone - it is the template's code volume measured against how long the
-case runs. A tiny case pays the instruction fetches and then exits before the cache
-warms.
-
-That makes `aic_icache_miss_rate` non-zero *only on small cases of an operator* a
-usable signal for "the code volume on this path is the cost", distinct from the two
-things it is usually read as (a bad access pattern, or a generally cold cache).
-
-## The stopping rule
-
-**Parameter-level knobs cannot move a per-invocation constant.** Taking this cost
-requires dropping below the API to `Load3D` + `Mmad` + `Fixpipe` and managing the
-pipeline yourself, which is an architecture-level project, not a tuning round.
-Deciding that before starting is the point of measuring it.
-
-The generic form of the diagnostic - build a deliberately wrong variant that skips
-the work loop, so what is left is the API's pure preamble - is in
-`ascendc-operator-optimization/references/measure-and-locate.md` section 1.2.

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

@@ -1,68 +0,0 @@
----
-id: pitfall-ascendc-matmul-c-to-ub-direct-launch
-title: "MIX Matmul Writing C to UB Does Not Run Under Direct Kernel Launch — 507015"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-cann_version: '9.1.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  Direct <<<blocks, l2ctrl, stream>>> launch under CANN 9.1.0. Kernels launched
-  through the operator framework take a different path and are unaffected - this is
-  about the launch mechanism, not about Matmul.
-tags:
-- ascendc
-- ai-core
-- cube-unit
-- ub
-- gemm
-hardware_features:
-- ai-core
-- cube-unit
-- ub
-kernel_types:
-- gemm
-related:
-- pitfall-ascendc-quant-matmul-output
-aliases:
-- "MIX C 出到 UB 起不来"
-- "507015"
-- "直调框架 Cube 只能落 GM"
----
-
-## P1. It compiles and it does not run
-
-`matmul::Matmul<>` + `REGIST_MATMUL_OBJ` + `IterateAll(ubTensor)` — C landing directly
-in UB — **compiles, then fails at runtime with `507015`**.
-
-Three things that look like the cause are all genuine bugs and **none of them is this
-one**:
-
-| Fix attempted | A real bug? | Still crashes? |
-|---|---|---|
-| bitmap tile rows 16 B → 32 B (`NK=256`) | ✅ yes | yes |
-| `REGIST_MATMUL_OBJ` is variadic `(pipe, ws, obj, tiling, obj, tiling)` — a tiling was missing | ✅ yes | yes |
-| `pipe.InitBuffer` placed outside `if ASCEND_IS_AIV` (**AIC has no UB**) | ✅ yes | yes |
-
-**Closing evidence:** a minimal reproduction at a fixed `32×128×128`, no strides, no
-loops, **zero business logic**, fails with the same `507015`.
-
-## P2. The likely mechanism
-
-A direct `<<<blocks, l2ctrl, stream>>>` launch **does not declare the MIX task type**
-(the AIC:AIV pairing), and KFC — the `MatmulClient` / `MatmulServiceAux` machinery —
-depends on that declaration. Vendor kernels go through the operator framework's launch
-path instead, and the declaring macro **cannot be found anywhere in this CANN release's
-headers (9.1.0)**.
-
-## P3. What to do
-
-> **Under a direct-launch framework, Cube results can only land in GM.** Do not model
-> reachability on the assumption that the epilogue can be fused into UB — that route
-> is not available, and the failure arrives after you have built around it.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/compute/matmul-direct-launch/tiling-entry.md

@@ -1,85 +0,0 @@
----
-id: skill-ascendc-vendor-tiling-entry-to-direct-launch
-title: "Converting a Vendor Kernel's Tiling Entry to Direct Launch"
-type: skill
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-evidence_level: measured
-cann_version: '9.0.0'
-confidence: experimental
-applies_to:
-- ascend910b
-scope: >-
-  Adapting an op_host/op_kernel-shaped vendor operator so it can be launched
-  directly with <<<blocks, l2ctrl, stream>>>. About the calling convention only -
-  what the kernel computes is unchanged. The compile-time-constant route assumes
-  a known, fixed set of shapes; it is not correct for an operator that must accept
-  arbitrary input.
-tags:
-- ascendc
-- ai-core
-source:
-- path: spec
-  anchor: Vendor op_kernel signature
-related:
-- pitfall-ascendc-matmul-c-to-ub-direct-launch
-- skill-ascendc-direct-launch-build-recipe
-aliases:
-- "官方 kernel 的 tiling 入口改直调"
-- "tiling 经 GM 传入"
-- "直调框架直接传 shape"
-- "op_kernel 签名"
-- "编译期常量 tiling"
----
-
-Tiling is the main difference between the two launch conventions, and it is a
-difference in the *signature*, not in the arithmetic.
-
-A vendor kernel is entered like this:
-
-```cpp
-__global__ __aicore__ void op(GM_ADDR x, GM_ADDR y, GM_ADDR workspace, GM_ADDR tiling)
-```
-
-The last argument is a pointer into global memory. The host side computed a
-tiling struct, wrote it to GM, and passed its address. A direct-launch build has
-no host-side tiling pass: it passes the shape itself. So the entry has to be
-rewritten, and there are two ways to do it.
-
-## Route 1 — keep the struct, fill it yourself
-
-Port `op_host/*_tiling.cpp` from the vendor tree, run it on the host, write the
-struct to GM, and keep the kernel signature as it is. The kernel body does not
-change at all.
-
-This is the route to take when the shape set is open, or when the vendor's tiling
-computation is itself the thing you want (it often encodes constraints - core
-counts, buffer budgets - that are not obvious from the kernel body). The cost is
-that you have carried a piece of the vendor host tree across, with whatever it
-depends on.
-
-## Route 2 — make the tiling a compile-time constant
-
-Replace the GM-borne struct with `constexpr` values and specialise. This is the
-route to prefer when the shape set is known and small: the compiler can then
-unroll the loops, fold the boundary tests, and allocate registers against real
-numbers instead of runtime values.
-
-That gain is the main structural advantage a specialised kernel has over a
-general-purpose library implementation, and its price is exact: **a kernel
-specialised this way is only correct on the shapes it was specialised for.** When
-the shape set changes, specialise again - do not expect it to generalise.
-
-## Related
-
-- The kernel is compiled with
-  [`skill-ascendc-direct-launch-build-recipe`](../../meta/vendor-reference/build-recipe.md).
-- Direct launch has a second consequence that is easy to design around by
-  mistake: [`pitfall-ascendc-matmul-c-to-ub-direct-launch`](./pitfalls.md) —
-  under a direct launch the MIX task type is never declared, so Cube results can
-  only land in GM.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/compute/measured-non-improvements/aiv-count-and-queue-depth.md

@@ -1,63 +0,0 @@
----
-id: pitfall-ascendc-aiv-count-and-queue-depth
-title: "Five Changes That Should Have Paid and Did Not — Including 48 AIV Being Worse Than 40"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-cann_version: '9.0.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  A memory-bound broadcast-reduction operator. The 48-vs-40 result is specific to a
-  kernel whose L2 bypass threshold was calibrated at 40 cores - it is a statement about
-  coupled parameters, not about core counts in general.
-tags:
-- ascendc
-- ai-core
-- vector-unit
-- ub
-- cache-policy
-- double-buffering
-hardware_features:
-- ai-core
-- vector-unit
-- ub
-techniques:
-- cache-policy
-- double-buffering
-related:
-- pitfall-ascendc-measured-non-improvements
-- technique-ascendc-l2-cache-hint
-aliases:
-- "预期有收益实际没有"
-- "48 AIV 比 40 更差"
-- "核数不是越多越好"
----
-
-## The table
-
-This is the most valuable kind of entry to write down, because every row is a change a
-competent person would try.
-
-| Tried | Expected | Measured | Why |
-|---|---|---|---|
-| **Gather-contiguous layout on the ROW path too** | as big as on the row-scalar path | case11 8.4 → **9.9 µs**, slower | building the index table (`CreateVecIndex` + 8 vector ops + `Gather`) is a **once-per-core fixed cost**, and case11 has only 4 tile rounds per core to amortize it over. **`Gather` pays only when the expansion has to be recomputed per tile.** |
-| `min_rounds` giving double buffering extra fill rounds | pipeline opens up on small cases | 0.698 vs 0.710, worse | with a smaller tile the per-tile fixed cost grows faster than the pipelining gains |
-| queue depth 3 | more DMA in flight | 84.64, inside noise | it traded away a third of the tile capacity, cancelling out |
-| L2 bypass threshold lowered to 20/60 MB | medium cases should benefit too | 83.8–84.0 vs 83.3–85.0 at 280 MB | on medium cases the L2 line fill is still acting as a prefetcher |
-| **48 AIV** (no core cap) | more cores, faster | **83.13 vs 85.40 at 40 AIV** | the L2 bypass threshold was calibrated at 40. **More cores is not monotonically better.** |
-
-## The one worth generalizing
-
-The last row is not "48 cores are bad". It is that **the core count and the L2 bypass
-threshold are one coupled parameter**, and moving either alone moves you off the
-calibrated point. Anything derived from a measurement at 40 cores — a traffic
-threshold, a tile size, a queue depth — has 40 baked into it.
-
-> Whenever a parameter was set by measurement, changing a *different* parameter
-> invalidates it. Re-calibrate, or change them together.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/compute/measured-non-improvements/matmul-knobs.md

@@ -1,83 +0,0 @@
----
-id: pitfall-ascendc-matmul-knobs-non-improvements
-title: "Five Matmul-Side Directions That Were Measured and Rejected"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910c
-languages:
-- ascendc
-cann_version: '9.1.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  One Conv2D operator, four on-device rounds, tiny-case-dominated shapes. Each row is
-  a direction that a mechanism argument recommends and measurement refused; a
-  different operator can revive any of them, and the HF32 row in particular is about
-  one accuracy threshold, not about HF32 in general. What does not need re-testing is
-  the reason each one failed.
-tags:
-- ascendc
-- cube-unit
-- ai-core
-hardware_features:
-- cube-unit
-- ai-core
-kernel_types:
-- gemm
-related:
-- pitfall-ascendc-matmul-api-fixed-cost
-- pitfall-ascendc-measured-non-improvements
-- hw-ascend-kernel-launch-floor
-sources: []
-aliases:
-- HF32
-- SetHF32Mode
-- doMultiDataLoad
-- doNorm
-- enableGetTensorC
-- basic block
-- kernel fusion
-- Matmul 模板
-- 判负方向
-- 合并 kernel
----
-
-## Search Keywords
-
-HF32, SetHF32Mode, doMultiDataLoad, doNorm, enableGetTensorC, basic block, basicM,
-basicN, kernel fusion, fuse kernels, measured non-improvement, Matmul 模板,
-判负方向, 合并 kernel, 缩小 basic block.
-
-## The table
-
-| Direction | Hypothesis | Measured | Why it failed |
-|---|---|---|---|
-| **HF32** (`SetHF32Mode(ENABLE)`) | ~2x throughput on fp32 matmul | three fp32 cases fail accuracy (relative error over threshold by 2.7-5.4x); the ones that pass gain only 1-3% | HF32 rounds its inputs at `2^-11` while the acceptance threshold is `2^-13` - **structurally incompatible**, not a tuning matter. Zero-mean data exceeds the threshold by construction; only a positive mean dilutes it, so there is **no legitimate predicate that separates the safe cases**. Selecting by shape is shape hardcoding, which is its own static check, `C6-hardcoded-shape`; selecting by value range means sampling data at run time |
-| **Shrink the Matmul basic block** (128x256 to 32x128) | the tile is 2700x larger than the real output | smallest two cases -7.5%, medium cases +14-17%, large cases +103% | the API only moves the real data via `SetSingleShape`, so a large tile wastes far less than it looks; the ceiling on this direction was under half a percent of the objective |
-| **Change the Matmul template** (`doMultiDataLoad` to `doNorm`) | MDL is the heaviest of the three templates | small cases -1-8%, large cases +4-8% | net flat, inside the noise band |
-| **Disable `enableGetTensorC`** | the feature is never called, so it inflates generated code and hurts icache | inside the noise band | the compiler had already eliminated the dead path |
-| **Fuse three kernels into one AIV kernel** | saves two launches | **+308% / +640%** | the launch saving is real but small - about 1 us per kernel removed - and the per-tap synchronisation the fusion introduces costs far more than that |
-
-## The fusion row is the interesting one
-
-The original write-up of this campaign explained the fusion result by saying the
-launch saving *was not counted at all*. That reason is wrong: a chained
-measurement on the same family of hardware shows each additional kernel adding
-**~1.02 us of device time, strictly linearly**, so removing a kernel does remove
-device time - see [the tiny-kernel device floor](../../../hardware/kernel-launch-floor.md).
-
-**The conclusion survived, the reason did not.** That is the more dangerous of the
-two failures: a wrong conclusion is wrong once, whereas a wrong reason extrapolates
-in every direction - "launch savings are not counted" would have pre-emptively killed
-every kernel-count reduction. The usable rule is the arithmetic one: **fusing buys
-back roughly 1 us per kernel removed, and is worth it only if the fusion adds less
-than 1 us of in-kernel synchronisation.**
-
-## What still holds after all five
-
-The Matmul parameter surface does not contain a fix for the per-invocation cost
-measured in [matmul-api-fixed-cost](../matmul-api-fixed-cost/pitfalls.md). Four of
-the five rows above are that same fact arrived at from four directions.

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

@@ -1,56 +0,0 @@
----
-id: pitfall-ascendc-measured-non-improvements
-title: "Two Rewrites That Sound Right and Measured Worse"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-cann_version: '9.0.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  Both readings are from a 40-core memory-bound elementwise kernel. The grid-stride
-  result depends on HBM ordering and should be re-measured on a kernel whose access
-  pattern is not sequential.
-tags:
-- ascendc
-- ai-core
-- vector-unit
-hardware_features:
-- ai-core
-- vector-unit
-related:
-- pitfall-ascendc-aiv-count-and-queue-depth
-- pitfall-ascendc-transpose-axpy-recurrence
-aliases:
-- "grid-stride 不要改"
-- "删 PipeBarrier 只快两三个点"
-- "负结果"
----
-
-## P1. Per-core contiguous ranges instead of grid-stride: 108 → 116 µs
-
-Grid-stride makes 40 cores advance in global order, which is friendlier to HBM.
-Replacing it with "one contiguous range per core" — which looks better for locality —
-measured **8% slower**.
-
-**Do not make this change.** The locality argument is about each core's own view; the
-memory system sees the union.
-
-## P2. Removing `PipeBarrier<PIPE_V>`: 2–3%, and not worth it
-
-The whole saving from deleting the barriers between dependent vector instructions is
-**2–3%**. The vendor's own built-in AscendC kernels
-(`opp/built-in/op_impl/ai_core/tbe/impl/ops_transformer/ascendc/**`) use them just as
-densely between dependent vector instructions.
-
-Two to three percent is not worth a race condition, and a race here is the kind that
-reproduces intermittently and only under load.
-
-> Both entries are here because they are the rewrites a reader will think of first.
-> They were measured so that the next person does not have to spend a round finding
-> out.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/compute/measured-non-improvements/transpose-axpy-recurrence.md

@@ -1,68 +0,0 @@
----
-id: pitfall-ascendc-transpose-axpy-recurrence
-title: "Transposing to a Reduction-Free Axpy Recurrence Is 27% Slower — Instruction Issue Is the Wall"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-cann_version: '9.0.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  The cost model below was calibrated on one serially recursive operator and used to
-  gate its dispatch. The 56 cycle constant is that kernel's issue cost; re-fit it
-  before reusing the model to decide anything.
-tags:
-- ascendc
-- ai-core
-- vector-unit
-- reduction
-hardware_features:
-- ai-core
-- vector-unit
-kernel_types:
-- reduction
-related:
-- pitfall-ascendc-whole-reduce-sum-cost
-- pitfall-ascendc-measured-non-improvements
-aliases:
-- "转置成 Axpy 递归更慢"
-- "指令发射代价"
-- "多路累加器不是解药"
----
-
-## P1. Optimal repeat count, worse time
-
-In theory, transposing `W` and accumulating with `Axpy` per `k` gives the optimal
-repeat count — there is no reduction at all. Measured: **54.7 → 71.2 µs**.
-
-Eliminated one at a time: swapping in a constant scalar (rules out `GetValue`'s
-vector-to-scalar round trip), swapping `Axpy` for `Add` (rules out `Axpy` itself) —
-both equally slow.
-
-**The cause is the ≈56 cycle issue cost of each vector instruction.** At E = 64 that
-is 64 instructions = 3584 cycle, which drowns the reduction that was saved.
-
-## P2. The cost model that came out of it
-
-```
-cost ≈ 56·(instruction count) + 2·(ordinary repeats) + 10.5·(vcadd repeats)
-```
-
-Every dispatch decision in that kernel was gated on this expression. The transposed
-form only wins when `padE ≪ 4·padH` (the projection case), which the model states
-directly.
-
-## P3. Multiple accumulators are not the remedy
-
-Breaking the `Axpy` dependency chain with **4 rotating accumulators** made it worse, in
-the same direction as an independent earlier measurement (995 → 1564 µs with 2 lanes →
-2302 µs with 4).
-
-> Both results say the same thing: when the wall is instruction **issue**, anything
-> that adds instructions to relieve a dependency stall makes it worse. Check which
-> wall you are against before applying a latency-hiding transform.