From 83d905fe7cd408aad559bc09ff1e163c17121bad Mon Sep 17 00:00:00 2001 From: admin Date: Tue, 25 Aug 2026 02:20:01 +0000 Subject: [PATCH] =?UTF-8?q?v0.9:=20MergeBatch=20vs=20IterBatch=20=E4=B8=80?= =?UTF-8?q?=E9=98=B6=E6=97=B6=E5=BB=B6=E6=A8=A1=E5=9E=8B=EF=BC=8C=E6=9D=A1?= =?UTF-8?q?=E4=BB=B61=E5=AE=9A=E4=BD=8D=E4=B8=BA=E4=BA=8C=E9=98=B6?= =?UTF-8?q?=E6=95=88=E5=BA=94=E5=90=AF=E5=8F=91=E5=BC=8F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- BMM算子优化分析_Release/BMM算子优化分析_v0.9.md | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/BMM算子优化分析_Release/BMM算子优化分析_v0.9.md b/BMM算子优化分析_Release/BMM算子优化分析_v0.9.md index ae9cda8..6f061d8 100644 --- a/BMM算子优化分析_Release/BMM算子优化分析_v0.9.md +++ b/BMM算子优化分析_Release/BMM算子优化分析_v0.9.md @@ -140,7 +140,20 @@ $$ 1. **batch 关系与每核份额**：无广播才能逐 batch 对应合并；每核至少分到 $2b_0$ 个 batch——$b_0$ 是合并搬移有收益的最小合并数（取 2），2 组起步才能构成合并组间乒乓流水（即 $b_{core} \ge 4$）。 - **为何不允许 $b_{core}=2$**（合并后每核仅 1 个合并 batch）：此时与 IterBatch（$b_{core}=2$，形态 b/d）对比——MergeBatch 合并后 $k_{L1}$ 减半（$L1/((2M{+}2N)\cdot\text{dtype})$ vs $L1/((M{+}N)\cdot\text{dtype})$），K 分块数翻倍；IterBatch 有 2 个 batch，每批 K 分块数不变。两者总 K 分块数相同、每块搬移量相同（均填满 L1），**总搬移时延相同**。访存 Bound 下（条件 5 保证），MergeBatch 的 2× 冗余计算在稳态流水中被搬移掩盖（第 $i$ 块计算与第 $i{+}1$ 块搬移交叠），总时延 ≈ IterBatch。但流水 drain 阶段（最后一个 K 分块无下一块搬移可交叠）计算暴露，MergeBatch 每分块计算量 = 2× IterBatch → drain 暴露也是 2×。K 分块数越少，暴露占比越大（$\sim T_{comp}/(n \cdot T_{load})$）；$b_{core} \ge 2b_0$ 确保合并后仍有 ≥2 个合并 batch 做 batch 级乒乓，且 $b_{core}$ 越大 MergeBatch 相对 IterBatch 的 dValue 优势越明显。 + **MergeBatch vs IterBatch 一阶时延模型**：设 $n_K = K/k_{L1}$（K 分块数），每分块搬移 $T_{load} = k_{L1}(M{+}N)\cdot\text{dtype}/BW_{pc}$，每分块计算 $T_{comp} = 2MN \cdot k_{L1}/Q_{16}$，输出写回 $T_{write} = MN \cdot outB/W_{GM}$。 + + IterBatch（$b_{core}$ 个 batch/核，unitflag 交叠 batch 间 drain/startup）： + $$T_{iter} = b_{core} \cdot n_K \cdot \max(T_{load}, T_{comp}) + T_{comp} + T_{write}$$ + + MergeBatch（合并后 $k_{L1}$ 减半 → $n_K$ 翻倍，每分块搬移量不变，每分块计算量 ×b₀，合并 batch 数 = $b_{core}/b_0$）： + $$T_{mb} = b_{core} \cdot n_K \cdot \max(T_{load},\; b_0 \cdot T_{comp}) + b_0(T_{comp} + T_{write})$$ + + 条件 5 保证合并后仍访存 Bound（$T_{load} > b_0 \cdot T_{comp}$），此时： + $$T_{mb} - T_{iter} = (b_0-1)(T_{comp} + T_{write}) > 0$$ + + **一阶模型下 MergeBatch 始终不优于 IterBatch**——稳态吞吐相同（总搬移量、每块大小、总块数都相同），MergeBatch 的 drain 暴露是 IterBatch 的 $b_0$ 倍。数值验证（B=128, M=N=64, K=512）：$T_{mb}/T_{iter} = 1.08$（MergeBatch 慢 8%，drain 占比 9.6% vs 2.6%）。 + + **条件 1 的定位**：不能从条件 2~5 推导。一阶模型未捕捉的二阶效应（GM 空间局部性、Cube 流水线填充效率、Fixpipe 大块写出效率）是 MergeBatch 的实际收益来源；$b_{core} \ge 2b_0$ 是确保二阶收益超过一阶惩罚 $(b_0{-}1)(T_{comp}{+}T_{write})$ 的保守启发式。 2. **L0C 容量**：合并 $b_0$ 个 batch 的输出块 $[b_0M, b_0N]$（FP32 累加、双缓冲两份）必须放得下 L0C；连最小合并都放不下，合并无从谈起。 3. **单核搬移总量**：单核搬移数据总量低于 min_DatamountPerCore 时，GM 带宽利用率上不去（重要性第 2 位的经验约束）。 4. **搬移 tile 大小**：单 batch 单矩阵的最大连续搬移块须达到 min_TileSize；合并是在此之上进一步放大，不是替代。