@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/experience/topk-publication-and-reuse.md

@@ -1,116 +0,0 @@
----
-id: exp-ascend-topk-publication-and-reuse
-title: 'TopK: preserve integer ordering, tie semantics and output-buffer reuse dependencies'
-type: experience
-vendor: ascend
-probe_slug: topk-publication-and-reuse
-measured_on:
-  device: Historical Ascend910B2C local runs and/or Ascend910C official runs; see
-    the source-bound scope
-source:
-- path: sources/experience/cannbench-optimization-history-20261020.md
-architectures:
-- ascend910b
-languages:
-- ascendc
-tags:
-- ascendc
-aliases:
-- TopK
-- top_k
-- 排序
-- GT13-r2
-- GT12
-- MTE3
-- heap
-- NaN
-- int64
-- exp-ascend-cannbench-20261020-topk-publication-and-reuse
-- wiki/ascend/experience/cannbench-20261020-topk-publication-and-reuse.md
-confidence: source-reported
-evidence_level: measured
-cann_version: unknown
-scope: AscendC heap/network variants, integer and FP16/BF16 contracts; local910B versus
-  formal910C, final GT13-r2 hidden qualification on2026-10-15.
-knowledge_id: knowledge-ascend-topk-publication-and-reuse
-knowledge_id_source: agent-semantic-link
-knowledge_scope: operator-local
-knowledge_page_role: operator-instance
-verified_operators: []
-observed_operators:
-- TopK
-condition_ids:
-- condition-cannbench-20261020-topk-publication-and-reuse
-sources:
-- exp-source-cannbench-optimization-20261020
-- exp-source-cannbench-branch-review
-source_refs:
-- source_id: experience/cannbench-optimization-20261020
-  path: evidence/topk-current.md
-- source_id: experience/cannbench-optimization-20261020
-  path: evidence/campaign-gelu.md
-- source_id: experience/cannbench-branch-review-20261020
-  path: evidence/20261015-52b1-topk-negative-closeout/CLOSEOUT.md
-- source_id: experience/cannbench-branch-review-20261020
-  path: evidence/20261015-52b1-topk-negative-closeout/GT20_VECTOR_UNIFORM_CLOSED.json
-- source_id: experience/cannbench-branch-review-20261020
-  path: evidence/20261015-52b1-topk-negative-closeout/GT21_FULLK_ISOLATION_CPU_CLOSED_CPU.json
-- source_id: experience/cannbench-branch-review-20261020
-  path: evidence/20261015-52b1-topk/PUBLISHED_GAIN.json
-- source_id: experience/cannbench-branch-review-20261020
-  path: evidence/20261015-52b1-topk/CANONICAL_PROMOTION.json
-related:
-- exp-ascend-cb06-discrete-oracle-domains
-evaluation_scope: public
-verification_status: historical-source-review; no independent rerun in this import
-kernel_types:
-- sort-select
----
-
-# TopK: preserve integer ordering, tie semantics and output-buffer reuse dependencies
-
-Historical **public** reference (2026-10-16T05:33:28.798747+00:00): **62.69159418, 20/20**. This is the selected aggregate at that capture, not a claim that an earlier checkpoint below produced the latest score. Keep the source-specific public baseline and its code identity.
-
-This refresh prioritizes public-set Kernaut evaluation. Historical hidden observations below are separate background; a hidden failure alone does not disqualify a public20/20 baseline. Benchmark pass, broader contract coverage and source integrity remain distinct.
-
-## Conditions and evidence status
-
-AscendC heap/network variants, integer and FP16/BF16 contracts; local910B versus formal910C, final GT13-r2 hidden qualification on2026-10-15.
-
-Historical source-reported evidence, reviewed on2026-10-20; no independent device reproduction in this import. `cann_version: unknown` refers to the combined record: individual local SDKs are stated where captured, and the official runner release is not assumed. Verified-operator coverage is left empty rather than inferred from historical scores.
-
-## Before and change
-
-**Before:** A public-passing GT12 source failed one hidden case; earlier int64 paths and extracted FP16 shared outputs had semantic and lifecycle counterexamples.
-
-**Change:** Retain exact integer ordering and all repair witnesses; gate any compressed-key route by its exact value-domain proof. Add the missing MTE3→V reuse dependency before overwriting the shared extracted FP16 output in the next loop generation. Check values, associated indices, cutoff ties and NaN payload rules separately.
-
-**Mechanism:** A DMA still reading an extraction buffer can race its next vector write even when one-iteration/public fixtures pass. Ordering/tie correctness is independent of apparent sorted values.
-
-## Recorded results
-
-GT13-r2 native qualification covered6947 records/24 groups, plus384 publication tests. Formal hidden job_25cda49767c3 passed80/80, score62.12251773839262, +.3913697990532228. Its own standard62.67000580874799 differs from older GT12 aggregate62.691594179963154.
-
-## Boundaries, negative evidence and reuse
-
-For the requested public-only benchmark, GT12 remains the recorded higher public baseline62.691594179963154/20; its hidden79/80 does not invalidate that public result. GT13-r2 is the repair alternative with its own slightly lower public score62.67000580874799. Extended-contract claims must still state the tested domain. Public-proxy +2.462876 did not predict the hidden+.391370. Later GT19/20 uniform routes had large uniform wins but13–19% ordinary/late-word regressions; unknown hidden hit rate does not erase measured losses. Histogram, scalar-label and event-reservation variants need their own route/cost evidence.
-
-Use the public parent for a new complete public comparison, keep all20 signed rows and AA controls, and bind the final build, source, task and checker. Do not require or launch a hidden evaluation for this public-only workflow.
-
-## Evidence
-
-- [topk-current](../../../corpus/ascend/cannbench/optimization-history-20261020/evidence/topk-current.md): exact input SHA256 and original line ranges.
-- [campaign-gelu](../../../corpus/ascend/cannbench/optimization-history-20261020/evidence/campaign-gelu.md): exact input SHA256 and original line ranges.
-- [Original operator chronicle](../../../corpus/ascend/cannbench/optimization-history-20261020/operator-records/top_k.json): preserved source text with its original paths and dates.
-
-Prior knowledge: `exp-ascend-cb06-discrete-oracle-domains`.
-
-[Public operator index](cannbench-public-experiences.md) · [source record](../../../sources/experience/cannbench-optimization-history-20261020.md)
-
-## Source tree and later closure do not change the public winner
-
-The branch's best source tree selects GT13-r2 after a hidden repair. Its own public62.67000581 remains below GT12 public62.69159418. Directory recency or a two-sided promotion is not permission to substitute that source for the public-only reference.
-
-The pinned [GT15–GT21 closure](../../../corpus/ascend/cannbench/branch-review-20261020/evidence/20261015-52b1-topk-negative-closeout/CLOSEOUT.md) supplements the historical summary: GT15 had1,251 semantic passes but zero observed public/hidden route hits; GT16/17 endpoint/histogram gains had ordinary-path regressions. GT19/20 raw/vector uniform routes had large uniform wins but repeatable ordinary/late-word losses; they are not general public performance recommendations. GT21 found zero uniform network tiles in reconstructed public generators and only strided public full-k routes. That was CPU generator reconstruction, not actual online seed/input observation, a build or a measured kernel. Preserve those qualifications and do not infer private distributions.
-
-The branch publication receipt now supplies an exact public-source binding: **GT12 job_ea9753e9c561, archive SHA256 `3426273614e550cc9ecd21b5acfd91253e7ed61aea6fe884aef801eb9b6e9e48`, public62.691594179963154**. Its identity is separate from the tree's GT13-r2. Inspect the [pinned publication receipt](../../../corpus/ascend/cannbench/branch-review-20261020/evidence/20261015-52b1-topk/PUBLISHED_GAIN.json) before reusing a source; matching a score or directory name alone is insufficient.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/experience/unique-packed-bitmap.md

@@ -1,116 +0,0 @@
----
-id: exp-ascend-unique-packed-bitmap
-title: 'Unique: exact packed keys, bitmap filtering and isolated device images'
-type: experience
-vendor: ascend
-probe_slug: unique-packed-bitmap
-measured_on:
-  device: Historical Ascend910B2C local runs and/or Ascend910C official runs; see
-    the source-bound scope
-source:
-- path: sources/experience/cannbench-optimization-history-20261020.md
-architectures:
-- ascend910b
-languages:
-- ascendc
-tags:
-- ascendc
-aliases:
-- Unique
-- 唯一值
-- UN203
-- UN202Q
-- U25Q
-- bitmap
-- coRank
-- NaN
-- exp-ascend-cannbench-20261020-unique-packed-bitmap
-- wiki/ascend/experience/cannbench-20261020-unique-packed-bitmap.md
-confidence: source-reported
-evidence_level: measured
-cann_version: unknown
-scope: Recorded FP16/BF16/raw16 and proven int64 packed routes, Ascend910B2C local
-  qualification and formal910C task1.1.2. Standard and hidden winners may use different
-  co-rank carriers.
-knowledge_id: knowledge-ascend-unique-packed-bitmap
-knowledge_id_source: agent-semantic-link
-knowledge_scope: operator-local
-knowledge_page_role: operator-instance
-verified_operators: []
-observed_operators:
-- Unique
-condition_ids:
-- condition-cannbench-20261020-unique-packed-bitmap
-sources:
-- exp-source-cannbench-optimization-20261020
-- exp-source-cannbench-branch-review
-source_refs:
-- source_id: experience/cannbench-optimization-20261020
-  path: evidence/campaign-slice.md
-- source_id: experience/cannbench-optimization-20261020
-  path: evidence/campaign-unique.md
-- source_id: experience/cannbench-optimization-20261020
-  path: evidence/campaign-unique-final.md
-- source_id: experience/cannbench-optimization-20261020
-  path: evidence/latest-offline.md
-- source_id: experience/cannbench-branch-review-20261020
-  path: evidence/20261015-52b1-unique/UN801_SCREEN.json
-- source_id: experience/cannbench-branch-review-20261020
-  path: evidence/20261015-52b1-unique/CPU_PROOF.json
-related:
-- exp-ascend-cb06-discrete-oracle-domains
-evaluation_scope: public
-verification_status: historical-source-review; no independent rerun in this import
-kernel_types:
-- sort-select
----
-
-# Unique: exact packed keys, bitmap filtering and isolated device images
-
-Historical **public** reference (2026-10-16T05:33:28.798747+00:00): **70.40668450, 20/20**. This is the selected aggregate at that capture, not a claim that an earlier checkpoint below produced the latest score. Keep the source-specific public baseline and its code identity.
-
-This refresh prioritizes public-set Kernaut evaluation. Historical hidden observations below are separate background; a hidden failure alone does not disqualify a public20/20 baseline. Benchmark pass, broader contract coverage and source integrity remain distinct.
-
-## Conditions and evidence status
-
-Recorded FP16/BF16/raw16 and proven int64 packed routes, Ascend910B2C local qualification and formal910C task1.1.2. Standard and hidden winners may use different co-rank carriers.
-
-Historical source-reported evidence, reviewed on2026-10-20; no independent device reproduction in this import. `cann_version: unknown` refers to the combined record: individual local SDKs are stated where captured, and the official runner release is not assumed. Verified-operator coverage is left empty rather than inferred from historical scores.
-
-## Before and change
-
-**Before:** Prefix initialization issued88 vector calls; a bitmap addition in the original device image also changed existing functions and incurred control regressions.
-
-**Change:** Reuse immutable indices/masks to reduce prefix calls88→40→25. Preserve raw low-precision values and task-specific signaling-NaN quieting; prove the int64 high-word condition before packing. Add exact seen-bit filtering in a separate device image, retaining old function texts, then qualify the final whole package.
-
-**Mechanism:** Reduce vector setup and redundant merge work without lossy key conversion. Image isolation helps distinguish algorithm changes from compiler effects on untouched functions.
-
-## Recorded results
-
-UN203 standard70.40668450446633/20 of20; bitmap target contribution+.107258813 and controls−.002471687, net+.1047871255. Final filter passed80 native plus719 domain checks. Separate image preserved179/179 old function texts; the original combined image changed7 and had whole20 mean−.075077.
-
-## Boundaries, negative evidence and reuse
-
-UN202Q hidden64.98779692641702/80 of80 and standard70.2338266997643 are one matching source; UN203 standard is another source. Do not advertise their sum as a tested single package. Zero-operator evaluator output was an invalid run. CPU conversion can itself quiet NaNs: integer-word oracles are needed. Later ordinary-path regressions in later uniform fast-path experiments remain exclusions.
-
-Use the public parent for a new complete public comparison, keep all20 signed rows and AA controls, and bind the final build, source, task and checker. Do not require or launch a hidden evaluation for this public-only workflow.
-
-## Evidence
-
-- [campaign-slice](../../../corpus/ascend/cannbench/optimization-history-20261020/evidence/campaign-slice.md): exact input SHA256 and original line ranges.
-- [campaign-unique](../../../corpus/ascend/cannbench/optimization-history-20261020/evidence/campaign-unique.md): exact input SHA256 and original line ranges.
-- [campaign-unique-final](../../../corpus/ascend/cannbench/optimization-history-20261020/evidence/campaign-unique-final.md): exact input SHA256 and original line ranges.
-- [latest-offline](../../../corpus/ascend/cannbench/optimization-history-20261020/evidence/latest-offline.md): exact input SHA256 and original line ranges.
-- [Original operator chronicle](../../../corpus/ascend/cannbench/optimization-history-20261020/operator-records/unique.json): preserved source text with its original paths and dates.
-
-Prior knowledge: `exp-ascend-cb06-discrete-oracle-domains`.
-
-[Public operator index](cannbench-public-experiences.md) · [source record](../../../sources/experience/cannbench-optimization-history-20261020.md)
-
-## Separate follow-up: UN801 owned-merge double buffering
-
-UN801 is not UN901, UN203 or the bitmap addition described above. Against literal UN203 ZIP `9bca4d34a3d2cb595d7f635dd5ad954f8944022860fd60c01e9a312287912629`, it adds two input/output slots in an isolated device image and prefetches the next chunk before merging the current one. Its 5,880-record chunk uses188,224 B UB, owns64-byte boundaries, and requires at least two real tasks per launched AIV; both slots drain.
-
-The seven-case ABBA screen passed28/28, with140 measured groups. Signed contributions with the full20 denominator were **−0.0225811381/−0.0255389853**, AA **+0.0012606571**, BB **−0.0016971901**. Merge slowed on four of five targets. The exact implementation was rejected; full20 and full-domain qualification were not run. Extra chunk/co-rank/dispatch cost is a causal hypothesis, not PMU proof or a universal double-buffer failure.
-
-The prior operator chronicle already preserves the mechanism; the [pinned structured screen](../../../corpus/ascend/cannbench/branch-review-20261020/evidence/20261015-52b1-unique/UN801_SCREEN.json) adds durable numeric evidence. The public reference70.40668450 is unchanged.

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

@@ -1,87 +0,0 @@
----
-id: skill-ascend-code-checklist
-title: "Ascend Kernel Code Quality Checklist"
-type: skill
-vendor: ascend
-tags:
-- triton-ascend
-- constexpr-parameters
-evidence_level: spec
-applies_to:
-- ascend910b
-source:
-- path: local
-  anchor: AscendOpGenAgent/skills
-architectures:
-- ascend910b
-languages:
-- triton-ascend
-techniques:
-- constexpr-parameters
-symptoms:
-- how to query number of ai cores vector cores at runtime
-- query device properties at runtime
-- get num_aicore num_vectorcore
-- persistent blocks near core count
-- 核数查询
-- 查询物理核数
-aliases:
-- get_device_properties
-- num_aicore
-- num_vectorcore
-- device properties
-- core count query
----
-# 代码规范检查清单
-
-在Ascend NPU上性能高效的triton算子，必须满足以下规范：
-
-## 必须遵循的规范
-
-### 1. 数据类型规范
-- [ ] 除非数值精度需要 int64 类型，否则禁止使用 int64 数据类型，必须使用 32 位数值类型进行计算
-
-### 2. 数值比较规范
-- [ ] 对于大于等于（>=）、大于（>）、小于等于（<=）、小于（<）四种数值比较操作，在不影响精度的情况下，必须转换成 fp32 数据类型，以启用向量化加速
-- [ ] 对于等于（==）、不等于（!=）两种数值比较操作，在不影响精度的情况下，必须转换成 fp32 或 int32 数据类型，以启用向量化加速
-
-### 3. 除法操作规范
-- [ ] 对于除法操作，在不影响精度的情况下，必须使用 fp32 或 int32 数据类型进行计算
-
-### 4. 模运算规范
-- [ ] 禁止直接使用 `a % b` 操作，必须使用 `a - (a / b) * b` 操作替代
-
-### 5. Grid 并行度规范
-- [ ] grid 并行数量禁止超过物理核数：
-  - 纯 vector 算子不可以超过 vector 单元数量
-  - 既包含矩阵计算及 vector 计算的 mix 算子禁止超过 cube 核数
-- [ ] 在任务数量超过核数时，确保获取了正确的核数，且所有核都被用上了
-- [ ] 禁止使用多维 grid，仅允许使用一维 grid
-
-获取核心数量的方法：
-```python
-from typing import Any, Dict, Tuple
-import torch
-import triton
-
-device = torch.npu.current_device()
-device_properties: Dict[str, Any] = (
-    triton.runtime.driver.active.utils.get_device_properties(device)
-)
-
-num_aicore = device_properties.get("num_aicore", -1)
-num_vectorcore = device_properties.get("num_vectorcore", -1)
-```
-
-### 6. Task 任务划分规范
-- [ ] task 任务划分禁止使用交织划分，每个 grid 任务处理的数据尽可能连续
-
-### 7. 控制流规范
-- [ ] 禁止在 triton 代码中使用 `continue` 和 `break` 语句
-
-## 检查流程
-
-1. 加载本文件（checklist.md）
-2. 逐一检查上述规范项
-3. 如有不满足项 → 修改代码直到满足所有规范
-4. 所有规范满足后 → 进行代码验证

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/compute/activation-highlevel-api/custom-gelu-primitive-regression.md

@@ -1,39 +0,0 @@
----
-id: pitfall-ascendc-custom-gelu-primitive-regression
-title: "AscendC：基础向量指令实现 Gelu 可能远慢于 aclnnGelu"
-type: pitfall
-vendor: ascend
-architectures: [ascend910b]
-soc: [ascend910b2c]
-languages: [ascendc]
-tags: [ascendc]
-confidence: inferred
-evidence_level: inferred
-cann_version: "9.1.0"
-sources: []
-knowledge_id: knowledge-custom-gelu-primitives-can-trail-vendor-kernel
-knowledge_id_source: agent-semantic-link
-knowledge_scope: conditional-general
-verified_operators: [custom_gelu]
-condition_ids: [condition-74bda4641999a4cd]
-scope: "Ascend 910B2C、CANN 9.1.0、fp32 连续 ND 大张量；对比 aclnnGelu"
----
-
-# AscendC：基础向量指令实现 Gelu 可能远慢于 aclnnGelu
-
-## 尝试
-
-host 按总元素数动态切分到 48 个 AIV，kernel 使用基础向量乘加和 tanh 近似实现 Gelu，并正确处理尾块。正确性从 156/168 修到 168/168。
-
-## 实测结果
-
-- 64 Mi 元素、50 次评测中，`aclnnGelu` 为 2.475 us，自定义实现为 433.111 us，约 0.006x。
-- 多次 1 Mi 元素测试约为基线的 0.31x。
-
-## 原因与边界
-
-动态切分解决了负载分配，基础指令组合也解决了接口可用性，但多轮向量运算、超越函数和中间缓冲读写仍远慢于当前 vendor 路径。该结论只覆盖当前 fp32 大张量和 CANN 版本，不能推广到其他 dtype、shape 或实现方式。
-
-这条证据也不能与“高阶激活 API 在某些固定形状上更慢”的既有页面合并：两者的基线、实现和条件不同，结论应并存。
-
-证据账本：`ledger-gelu-primitive-vector`。

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

@@ -1,68 +0,0 @@
----
-id: pitfall-ascendc-activation-highlevel-api
-title: "CANN's Built-in Activation High-Level APIs Are Slower Than a Specialized Kernel"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910c
-languages:
-- ascendc
-cann_version: '9.1.0'
-evidence_level: measured
-confidence: experimental
-status: correction
-scope: >-
-  Fixed-shape, fixed-dtype kernels where the specialization the vendor API cannot make
-  is exactly what wins. On a kernel that genuinely has to handle many shapes and
-  dtypes, the vendor implementation is doing work you would otherwise have to write.
-tags:
-- ascendc
-- ai-core
-- vector-unit
-- elementwise
-hardware_features:
-- ai-core
-- vector-unit
-kernel_types:
-- elementwise
-related:
-- pitfall-ascendc-transcendental-power
-aliases:
-- "CANN 激活高阶 API 被证伪"
-- "先查再手写 不成立"
----
-
-## The claim this page retracts
-
-An earlier recommendation said: before hand-writing an activation, look for CANN's
-implementation in `lib/activation/` and use it. **That was measured and is wrong.**
-
-Rewriting Sigmoid / Gelu / Softmax onto the `lib/activation/` implementations kept
-accuracy identical (every case still passed) and cost performance:
-
-| Operator | Before | With the high-level API |
-|---|---:|---:|
-| Sigmoid | 1.18× baseline | **1.19×** — no change |
-| Gelu | 1.46× | **1.77×** — **21% worse** |
-| Softmax | 3.56× | **6.07×** — **70% worse** |
-
-(Ratios are time against the vendor baseline, so larger is slower.)
-
-**Cause.** The vendor implementation carries generality: shape and dtype branching,
-scratch-buffer management. On a kernel whose shapes and dtypes are fixed, that
-generality is pure overhead against a specialized hand-written path.
-
-## What survives, and what does not
-
-- **Keep**: reading `lib/` once is worth it. Knowing what pre-built pieces exist
-  costs one pass and occasionally saves a whole implementation.
-- **Discard**: "look it up first, then hand-write" as a *default strategy*. Any use of
-  a high-level API has to be justified by a measured A/B against the specialized form,
-  on your own shapes.
-
-> The general lesson is not about activations. **A vendor API is optimized for the
-> distribution of inputs the vendor expects, and your kernel's distribution is
-> narrower.** Whenever the narrowing is the source of your speedup, a general
-> implementation cannot keep it.

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

@@ -1,73 +0,0 @@
----
-id: pitfall-ascendc-bitwise-16bit-lanes
-title: "Ascend C Bitwise Ops Count 16-Bit Lanes — int32 Silently Half-Processed"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910c
-languages:
-- ascendc
-cann_version: '9.1.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  Confirmed for Or on int32 under CANN 9.1.0. And / Not / ShiftLeft share the
-  16-bit-only surface and are covered by the same rule; the exact wrong-output
-  fraction (25%) is a property of the tested shape, not a constant.
-tags:
-- ascendc
-- ai-core
-- vector-unit
-hardware_features:
-- ai-core
-- vector-unit
-related:
-- technique-ascendc-vector-repeat-granularity
-source:
-- path: sources/experience/ascend-campaign/ascend910c-vector-repeat-and-dtype-lanes.md
-  anchor: B. `AscendC::Or` is a 16-bit operation
-aliases:
-- "Or 是 16 位"
-- "int32 静默只处理一半的字"
----
-
-## P1. `AscendC::Or` on an `int32` tensor compiles and processes half the words
-
-**Symptom.** Accuracy fails on part of the output with no error, no warning and no
-compile diagnostic. The wrong elements are not random: **every high half-word is
-zero**. Measured on AdaptiveAvgPool3D, exactly 25% of the output was wrong.
-
-**Cause.** The bitwise ops are 16-bit operations. `count` is counted in **16-bit
-lanes**, so a call written for `int32` covers half the words it appears to cover.
-The template parameter accepts `int32_t`; the hardware lane width does not change
-to match it.
-
-**Fix.** Do mask arithmetic on a `uint16` view and double the count:
-
-```cpp
-// WRONG — compiles, runs, leaves every high half-word at zero:
-AscendC::Or(dstI32, srcAI32, srcBI32, count);
-
-// RIGHT — reinterpret to the width the instruction actually operates on:
-auto dst16  = dst.template ReinterpretCast<uint16_t>();
-auto srcA16 = srcA.template ReinterpretCast<uint16_t>();
-auto srcB16 = srcB.template ReinterpretCast<uint16_t>();
-AscendC::Or(dst16, srcA16, srcB16, count * 2);   // count in 16-bit lanes
-```
-
-**Detection.** Dump the output as `uint16` pairs and check whether the odd lanes
-are uniformly zero. A whole-tensor comparison against the reference will report a
-plausible-looking error rate and tell you nothing about the mechanism.
-
-## P2. The general rule this is an instance of
-
-The dtype semantics of an Ascend C bitwise API and its template parameter are two
-different things. **An instantiation that compiles is not evidence that the
-instruction operates at the width you asked for.**
-
-Before using any bitwise op at a width other than 16 bits, confirm the width with
-a one-element probe whose answer differs between the two hypotheses — do not infer
-it from the fact that the code built. This class of defect is a **silent** failure,
-not a loud one, so nothing in the build or the run will raise it for you.

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

@@ -1,67 +0,0 @@
----
-id: pitfall-ascendc-block-count-granularity
-title: "blockCount Granularity Must Not Be Copied from the Tile Size"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-cann_version: '9.1.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  The right granularity is the minimum work that keeps the vector path engaged, which
-  is dtype-dependent - 256 elements for an int64 path here. Going below it pushes the
-  tile out of the vector path and costs more than the starvation it fixes.
-tags:
-- ascendc
-- ai-core
-- vector-unit
-hardware_features:
-- ai-core
-- vector-unit
-related:
-- technique-ascendc-vector-repeat-granularity
-aliases:
-- "blockCount 粒度"
-- "核饥饿"
-- "别照抄 tile 大小"
----
-
-## P1. `blockCount = min(cores, total / tileElements)` starves small inputs
-
-The divisor is the **vector tile size**, so an input that happens to be exactly one
-tile is handed **one core**. Measured: a 4096-element case ran **681.9 µs** where the
-reference implementation took 10.0 µs — **68× slower**. Across a wider shape sweep,
-16 of 80 shapes were core-starved to some degree.
-
-**The granularity has to come from the minimum useful vector work, not from the tile
-size.** For the operator measured that was 256 elements
-(`kInt64VectorMinElements`); below it the int64 tile falls out of the vector path and
-the change backfires.
-
-```cpp
-// WRONG — divisor is the tile size, so one tile means one core
-blockCount = min(coreNum, total / tileElements);
-
-// RIGHT — divisor is the smallest chunk that still runs on the vector path
-constexpr uint32_t kVectorMinElements = 256;     // dtype-dependent, measure it
-blockCount = min(coreNum, (total + kVectorMinElements - 1) / kVectorMinElements);
-```
-
-After the change the 4096-element case dropped to **45.3 µs**, while every shape at
-or above `cores × tileElements` was untouched — interleaved A/B gave
-`Δ = +0.0033, t = 0.1`.
-
-## P2. You cannot find this with the shapes you were given
-
-Shapes supplied with a task are usually large enough to fill the cores already, so
-they exercise neither the bug nor the fix. The only way to price it is a **synthetic
-probe built at the element counts you expect to meet**, using the shapes you do have
-to confirm **no regression** rather than to demonstrate the gain.
-
-> This is the general shape of a starvation defect: it is invisible on exactly the
-> inputs that are easiest to test.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/compute/broadcast-max/techniques.md

@@ -1,88 +0,0 @@
----
-id: technique-ascendc-broadcast-max-levers
-title: "Broadcast-Reduction Operators — the Four Levers That Actually Paid"
-type: technique
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-cann_version: '9.0.0'
-evidence_level: measured
-confidence: experimental
-reproducibility: snippet
-scope: >-
-  A broadcast-then-reduce operator on DAV_2201. Lever 2's magnitude depends on how
-  wide the broadcast is; lever 3 requires the row length to be 32 B aligned already
-  and does nothing otherwise.
-tags:
-- ascendc
-- ai-core
-- vector-unit
-- ub
-- reduction
-- discrete-memory-access
-- double-buffering
-hardware_features:
-- ai-core
-- vector-unit
-- ub
-kernel_types:
-- reduction
-techniques:
-- discrete-memory-access
-- double-buffering
-prerequisites:
-- hw-ascend910b2c
-related:
-- technique-ascendc-l2-cache-hint
-- technique-ascendc-reduction-cost-overview
-sources:
-- exp-ascend910b2c-reduction-and-broadcast-costs
-source:
-- path: sources/experience/ascend-campaign/ascend910b2c-reduction-and-broadcast-costs.md
-  anchor: Broadcast path rewrites, same campaign
-aliases:
-- "广播归约 四个杠杆"
-- "Gather 展开"
-- "Brcb repeat stride"
----
-
-## The four that moved, in order of size
-
-| Change | Effect |
-|---|---|
-| `SetL2CacheHint<READ>(DISABLE)`, gated at >280 MB total traffic | 602→439 µs · 273→186 · 270→185 · 182→138 |
-| broadcast replaced by **rows packed contiguously + one `Gather` to expand** | **2455→41.7 µs** · 1082→44.8 |
-| `Brcb` + repeat-stride `Max`, where the row is already 32 B aligned | 41.6→27.4 µs |
-| double-buffered `TQue`, flattened tile, `DataCopy` without pad on aligned tiles | 0.74→0.89 (ratio) |
-
-And separately, on an int64 path: replacing a scalar loop with **7 full-width
-instructions** took it from **12116 µs to 186 µs**.
-
-## Why the Gather rewrite is worth 59×
-
-The naive broadcast issues one small transfer per row. Packing the rows so that one
-transfer carries a contiguous run, then paying a single `Gather` to re-impose the row
-layout inside UB, moves the work from the DMA issue path to the vector unit:
-
-```cpp
-// ubPacked, ubRows: LocalTensor<float>;  rowOffsets: LocalTensor<uint32_t>
-// one burst for the whole run of rows, then one Gather to expand
-const uint16_t runBytes = static_cast<uint16_t>(runElems * sizeof(float));
-DataCopyPad(ubPacked, gmIn[base], {1, runBytes, 0, 0}, padParams);
-Gather(ubRows, ubPacked, rowOffsets, 0, runElems);
-```
-
-This is the same mechanism as
-[`technique-ascendc-datacopypad-burst-cost`](../../memory/datacopypad-burst/techniques.md):
-below one DMA transaction the per-burst issue cost dominates, and the fix is always to
-make the bursts bigger and repair the layout in UB.
-
-## The alignment precondition on lever 3
-
-`Brcb` plus a repeat-strided `Max` only works when the row length is **already** 32 B
-aligned. Padding rows to make it true costs more than the lever returns; check first,
-and fall back to the `Gather` form when it is false.