admin/matmul-analysis
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

34. ASW_Basic 兜底必须恒出方案: 搬移效率下限不满足应降级标注(warning), 不是违规/不可行 #34

New Issue
Closed
opened 2026-09-07 08:15:08 +00:00 by admin · 1 comment
admin commented 2026-09-07 08:15:08 +00:00
Owner
Copy Link

背景

两个问题(用户复核 b32_m16_n8192_k7168 引出):

  1. 分解推导说明: k_l1=112 = L1 双缓冲容量对 tile 周长 (16+1024) 的反推
    (⌊524288/(2·(16+1024)·2)⌋16 = 112); 严格枚举因 dValue 256B 偏好不可满足
    (Base 整数倍粒度下 k_l1·dt 最高 224B) 而落空, 经放开约束 4 的 128B 硬下限兜底选出;
  2. 策略语义: ASW_Basic 是兜底分支 —— "不符合之前分支的 case 都要能在 ASW_Basic 给出实现方案"。
    当前把"搬移效率下限不满足"当成违规/不可行(feasible=False)处理是不对的:
    dValue/minTile 是效率下限(DMA 仍能工作, 只是突发效率低), 不是硬件不可行;
    真正不可行的只有容量/核数类硬约束 (L0C/L0A/L0B/L1 超容, used_core_num 超核数)。

修复

  • constraints.py: ASW_Basic / ASW_Basic_降核 的 dValue 效率下限不再计违规
    (IterBatch/MergeBatch/StreamK 等有替代分支的分支仍按违规处理——不满足条件不该进);
  • asw_basic 枚举: 严格 256B 偏好无解 -> 放开约束 4 按 128B 硬下限给最优可行 tile,
    note 标注 效率降级 (效率低于模型假设, 时延可能低估, 建议调 dtype/布局);
    128B 硬下限也不满足的极端形状 (如 N=8 int8: B 侧 dValue = sN·dt = 8B 物理不可满足)
    仍给方案 + 标注效率降级 (搬移效率崩塌), 不再是"违规/不可行";
  • evaluator advice / 仲裁文案同步包含"效率降级"提示;
  • 回归: 极端形状恒出方案且 feasible=True + 标注效率降级; 兜底恒不崩溃/恒有时延;
    压力 10000 例 0 崩溃/0 NaN/0 硬违规。
## 背景 两个问题(用户复核 b32_m16_n8192_k7168 引出): 1. **分解推导说明**: k_l1=112 = L1 双缓冲容量对 tile 周长 (16+1024) 的反推 (⌊524288/(2·(16+1024)·2)⌋16 = 112); 严格枚举因 dValue 256B 偏好不可满足 (Base 整数倍粒度下 k_l1·dt 最高 224B) 而落空, 经放开约束 4 的 128B 硬下限兜底选出; 2. **策略语义**: ASW_Basic 是兜底分支 —— "不符合之前分支的 case 都要能在 ASW_Basic 给出实现方案"。 当前把"搬移效率下限不满足"当成**违规/不可行**(feasible=False)处理是不对的: dValue/minTile 是**效率下限**(DMA 仍能工作, 只是突发效率低), 不是硬件不可行; 真正不可行的只有容量/核数类硬约束 (L0C/L0A/L0B/L1 超容, used_core_num 超核数)。 ## 修复 - constraints.py: ASW_Basic / ASW_Basic_降核 的 dValue 效率下限不再计违规 (IterBatch/MergeBatch/StreamK 等**有替代分支**的分支仍按违规处理——不满足条件不该进); - asw_basic 枚举: 严格 256B 偏好无解 -> 放开约束 4 按 128B 硬下限给最优可行 tile, note 标注 **效率降级** (效率低于模型假设, 时延可能低估, 建议调 dtype/布局); 128B 硬下限也不满足的极端形状 (如 N=8 int8: B 侧 dValue = sN·dt = 8B 物理不可满足) 仍给方案 + 标注效率降级 (搬移效率崩塌), 不再是"违规/不可行"; - evaluator advice / 仲裁文案同步包含"效率降级"提示; - 回归: 极端形状恒出方案且 feasible=True + 标注效率降级; 兜底恒不崩溃/恒有时延; 压力 10000 例 0 崩溃/0 NaN/0 硬违规。
admin closed this issue 2026-09-07 08:24:49 +00:00
admin commented 2026-09-07 08:25:43 +00:00
Author
Owner
Copy Link

修复 commit: 0cd47f9

先答第 1 问 (分解推导链): b32_m16_n8192_k7168 的 k_l1=112 分解过程

  1. BaseM/BaseN: M=16<256 -> 例外跟随 M: BaseM=16; 另一侧 BaseN = min(L0C 面积余量 4096,
    N=8192, L0B 单边上限 64KB/(2·16·2)=1024) = 1024; BaseK=16 (L0B 双边 64KB 恰满);
  2. SingleCore 枚举: B=32=C -> P=1 先试不切分 (16×8192): k_l1 被 L1 压到 16 -> dValue
    32B < 256B 偏好 ✗; 有界枚举 (mCnt=1, nCnt<=8): 候选 (1,8) 即 sN=1024 -> k_l1 =
    min(7168, ⌊L1/(2·(16+1024)·2)⌋16 = ⌊126⌋16 = 112) = 224B —— 未达 256B 偏好
    (Base 整数倍粒度下达不到), 但 ≥ 128B 硬下限 -> 按放开约束 4 的兜底路径选出;
  3. 物理含义: 每 tile (16×1024) 按 k_l1=112 元素 (224B/行) 双缓冲分段搬入 K=7168,
    A 行带 [16×7168]=229KB + B 列带 [7168×1024]=14.7MB。

第 2 问 (语义分层修正):

  • 之前 "违规/不可行" 的口径不对: dValue/minTile 是效率下限(DMA 仍能工作, 只是突发效率低),
    不是硬件不可行; 真正不可行的只有容量/核数硬约束 (L0C/L0A/L0B/L1 超容, 核数超限);
  • 兜底分支 (ASW_Basic) 恒出方案: 效率下限不满足时降级标注 (plan.note 含"效率降级",
    advice/仲裁文案同步提示), feasible=True, 时延照常给出;
  • 有替代分支的分支 (IterBatch/MergeBatch/StreamK 等) 仍按违规处理 (不满足条件不该进)。

落地:

  1. constraints.py: ASW_Basic/ASW_Basic_降核 的 dValue 下限不再计违规;
  2. asw_basic 枚举尾部三级: 严格 256B 偏好 -> 放开约束 4 按 128B 硬下限 -> 极端兜底,
    后两级 note 均标注"效率降级";
  3. evaluator advice / router 仲裁文案含"效率降级"提示;
  4. docs/06 Step1 加"兜底分支恒出方案"段落。

验证: 63/63 全过 (新增分解推导回归 b32_m16_n8192_k7168 -> k_l1=112, 极端形状 feasible

  • 效率降级标注); 压力 10000 例 0 崩溃/0 NaN/0 硬违规/0 GM<V_in; examples 重生成 0 diff;
    demo 集仅 b32_m16_n8192_k7168 带效率降级标注 (符合预期)。
修复 commit: 0cd47f9 **先答第 1 问 (分解推导链)**: b32_m16_n8192_k7168 的 k_l1=112 分解过程 1. BaseM/BaseN: M=16<256 -> 例外跟随 M: BaseM=16; 另一侧 BaseN = min(L0C 面积余量 4096, N=8192, L0B 单边上限 64KB/(2·16·2)=1024) = 1024; BaseK=16 (L0B 双边 64KB 恰满); 2. SingleCore 枚举: B=32=C -> P=1 先试不切分 (16×8192): k_l1 被 L1 压到 16 -> dValue 32B < 256B 偏好 ✗; 有界枚举 (mCnt=1, nCnt<=8): 候选 (1,8) 即 sN=1024 -> k_l1 = min(7168, ⌊L1/(2·(16+1024)·2)⌋16 = ⌊126⌋16 = **112**) = 224B —— 未达 256B 偏好 (Base 整数倍粒度下达不到), 但 ≥ 128B 硬下限 -> 按放开约束 4 的兜底路径选出; 3. 物理含义: 每 tile (16×1024) 按 k_l1=112 元素 (224B/行) 双缓冲分段搬入 K=7168, A 行带 [16×7168]=229KB + B 列带 [7168×1024]=14.7MB。 **第 2 问 (语义分层修正)**: - 之前 "违规/不可行" 的口径不对: dValue/minTile 是**效率下限**(DMA 仍能工作, 只是突发效率低), 不是硬件不可行; 真正不可行的只有容量/核数硬约束 (L0C/L0A/L0B/L1 超容, 核数超限); - 兜底分支 (ASW_Basic) 恒出方案: 效率下限不满足时**降级标注** (plan.note 含"效率降级", advice/仲裁文案同步提示), feasible=True, 时延照常给出; - 有替代分支的分支 (IterBatch/MergeBatch/StreamK 等) 仍按违规处理 (不满足条件不该进)。 落地: 1. constraints.py: ASW_Basic/ASW_Basic_降核 的 dValue 下限不再计违规; 2. asw_basic 枚举尾部三级: 严格 256B 偏好 -> 放开约束 4 按 128B 硬下限 -> 极端兜底, 后两级 note 均标注"效率降级"; 3. evaluator advice / router 仲裁文案含"效率降级"提示; 4. docs/06 Step1 加"兜底分支恒出方案"段落。 验证: 63/63 全过 (新增分解推导回归 b32_m16_n8192_k7168 -> k_l1=112, 极端形状 feasible + 效率降级标注); 压力 10000 例 0 崩溃/0 NaN/0 硬违规/0 GM<V_in; examples 重生成 0 diff; demo 集仅 b32_m16_n8192_k7168 带效率降级标注 (符合预期)。
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
admin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: admin/matmul-analysis#34
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?