admin
b0b48b9073
用户澄清: MergeBatch vs IterBatch 的本质区别不只是 DMA 命令数 —— 合并 b0 个 batch 的左/右矩阵一起搬入 L1, 使单块 tile = nValue*dValue*dt 放大 b0 倍 (堆叠 方向视转置: A ND 非转置沿 M(nValue), B ND 非转置沿 N(dValue)), 搬移效率更高, 即便 T_cmd=0 也有效益。 - models.move_eff: 单命令搬移效率 eff = min(1, tile/min_TileSize) (16KB 饱和, 与进入条件4效率下限语义同源); gm_move_time 按 A/B 两侧字节加权 t = (V_A/eff_A + V_B/eff_B)/BW_gm; 只影响时间列, GM 字节量仍 = V_in - IterBatch: l1_form 补驻留侧返回; move_tiles 分侧口径 (a/b 双侧整K, c 驻留侧 整K+对侧k_l1, d 双侧k_l1), evaluate 接入效率加权 - MergeBatch: 合并 tile 放大 b0 倍接入效率加权; beats_iterbatch 净收益 = 命令节省(cmds差×T_cmd) + 效率节省(t_data差) − drain惩罚, K截断且效率打平且 T_cmd>0 时严格退化为 v1.1 §4.5 闭式; 退役 T_cmd<=0 策略特判 - router: 退役 "T_cmd<=0 策略优先 MergeBatch" 覆盖, 时延模型统一终审 - hardware: t_cmd_ns 50 -> 0 (未标定按 0; 合并收益不再依赖 T_cmd 估计值) - 作用域: 仅切B 两分支接入 (逐命令 tile 小、效率差显著); ASW/StreamK 单命令 tile 通常已饱和, 极端小 tile 走 issue#34 效率降级标注通道 - 用户 case 家族 B=128,M=1~16,N=128,K=512: m=1~8 -> MergeBatch (效率节省 ~0.61us > drain), m=16 -> IterBatch (iter A tile 恰达 16KB 饱和, 效率打平, drain 决定); 分界与时延全家族一致 - demo: merge_demo_k_trunc 形状 (2048,32,32,256)->(2048,16,64,128) (原形状 两侧 tile 均已 16KB 饱和, t_cmd=0 下无收益转 IterBatch; 新形状 iter A tile 4KB eff=0.25 vs 合并 16KB eff=1.0, 保持 MergeBatch 胜出演示且仍 K截断) - 测试: 74/74 (新增 TestIssue36 5 例: 效率曲线/字节不变/效率差胜出/家族; TestArbitration/TestZeroCmdHandling 按 t_cmd=0+效率语义重写; TestIssue35 家族期望更新) - 文档: 01_MergeBatch §4/§5 效率模型+泛化净收益; 02_IterBatch 口径注; 00_总纲胜出条件; 01_软件架构 T_cmd 标定说明; 05 时间列效率口径注; README 要点 - 验证: examples 重生成可复现 0 diff; 压力 10000 例 0 崩溃/0 NaN/0 违规/ 0 GM<V_in, 七分支覆盖 (MergeBatch 386 例)
6.9 KiB
MergeBatch 分支理论
整理自《BMM算子优化分析 v0.98》§五 + 《MergeBatch_vs_IterBatch分析 v1.1》§三/§四. 对应软件实现:
bmm_theory/branches/merge_batch.py.
1. 一句话本质
核间切 B（每核 b_core = B/C 个 batch），核内把 b₀ 个 batch 合并成大矩阵做单次 DMA 搬入、一次计算、一次写回：
[b_0 M, K] @ [K, b_0 N] = [b_0 M, b_0 N],\quad \text{BlockTrace 取对角线得 } [b_0, M, N]
交叉项被算出但丢弃（冗余比例 (b₀−1)/b₀）——冗余算力换搬移效率，进入条件 5 保证 case 为访存 Bound，冗余被搬移时延掩盖。
2. 进入条件（5 条同时满足）
| # | 条件 | 物理含义 |
|---|---|---|
| 1 | BatchA = BatchB 且 b_core = B/C ≥ 2b₀ (≥4) | 无广播才能逐 batch 对应合并；每核至少 2 组构成合并组间乒乓 |
| 2 | 2·(b₀M)(b₀N)·4B ≤ L0C (256KB) | 合并后输出放得下 L0C 双缓冲；连最小合并都放不下则无从谈起 |
| 3 | b_core·(MK+KN)·dtype ≥ 480KB | 单核搬移总量足够，GM 带宽利用率才上得去 |
| 4 | max(MK, KN)·dtype ≥ 16KB | 单 batch 单矩阵最大连续搬移块达到 min_TileSize |
| 5 | 2MN/(M+N) < R₁₆/b₀ | 合并放大算存比 b₀ 倍后仍访存 Bound，瓶颈留在搬移侧 |
3. 实现方案（4 步）
Step 1: 合并数 b₀（L0C + 算存比双上限，尽量取 b_core 的因子）
b_0 = \min\Big(\sqrt{\frac{L0C}{2\cdot MN\cdot 4B}},\; \frac{R_{16}(M+N)}{2MN},\; b_{core}\Big)
Step 2: L0 级 K 粒度 k_L0 = min(L0A/(2·b₀M·dt), L0B/(2·b₀N·dt)) 向下 16 对齐
Step 3: L1 级 k_L1（先反推再截断）
k_{L1}^* = \frac{L1}{2\cdot b_0\cdot(M+N)\cdot dt},\qquad k_{L1} = \min(k_{L1}^*,\; K,\; 512B/dt)
不超过 K（K 截断），不超过 dValue 推荐值 512B（更大无额外收益）。
Step 4: b_L1 最大化
b_{L1} = \min\Big(\frac{L1}{2\cdot k_{L1}\cdot(M+N)\cdot dt},\; b_{core}\Big) \ge b_0
k_L1 被 512B 截断省出的 L1 空间容纳更多 batch，提升 batch 间流水深度。
4. 时延模型（v1.1 §4）
符号：T_load = k_L1(M+N)·dt/(BW_pc·eff)（每 K 分块搬移，eff=move_eff(单命令tile)，见下）、T_comp = 2MN·k_L1/Q₁₆（每 K 分块计算）、T_write = MN·outB/W_GM（单 batch 写回）、T_cmd（单次 GM→L1 DMA 固定开销，默认按 0——未标定；issue#36 起合并收益由搬移效率模型刻画，不依赖 T_cmd 估计值）。
搬移效率模型 (issue#36, 用户澄清): 单命令搬移效率由单块 tile = nValue×dValue×dt 决定 —— eff(tile) = min(1, tile/min_TileSize)，达 16KB 饱和、之下线性退化 (与进入 条件 4 的效率下限语义同源)。合并 b0 个 batch 使单块 tile 放大 b0 倍 (A 侧 b0·M·k_L1^m·dt, B 侧 b0·N·k_L1^m·dt; 堆叠方向视转置/排布: A ND 非转置沿 M(nValue) 堆叠, B ND 非转置沿 N(dValue) 堆叠, 乘积不变), 相对 IterBatch 逐 batch 搬移 (A 侧 tile = M·k_L1^iter·dt) 效率更高 —— 即便 T_cmd=0 也有收益。 GM→L1 数据时延按两侧字节加权: t_data = (V_A/eff_A + V_B/eff_B)/W_GM; GM 字节量不变 (仍 = V_in)。效率模型只接入切B 两分支 (逐命令 tile 小、效率差显著); ASW/StreamK 单命令 tile 通常 ≥ 数百 KB 已饱和 (极端小 tile 形状有"效率降级"标注通道, issue#34)。
T_{mb} = \underbrace{\frac{b_{core}}{b_0}\cdot n_K^m\cdot(T_{load}^m + T_{cmd})}_{\text{搬移(合并)}} + \underbrace{b_0(T_{comp}+T_{write})}_{\text{末合并 batch drain}}
两种经典情形 (v1.1 §4.3/§4.4) 与第三情形 (issue#35):
| 情形 | k_L1^m | n_K^m | 每核搬移命令数 (⌈b_core/b₀⌉·n_K^m) | 结论 |
|---|---|---|---|---|
| K 截断 (k_L1^m=K) | K | 1 | ⌈b_core/b₀⌉（比 IterBatch 少 b₀ 倍） | MergeBatch 可胜 |
| L1 绑定 (k_L1^m=k_L1^iter/b₀) | k_L1^iter/b₀ | b₀·n_K | b_core·n_K（与 IterBatch 相同） | MergeBatch 恒劣 |
| dValue cap 截断 (k_L1^m=512B/dt, 文档二分未覆盖) | 512B/dt | ⌈K/k_L1^m⌉ | 按实际比较 (可与 IterBatch 打平或少) | 按泛化分界判定 |
L1 绑定理想情形搬移次数、单次搬移量都与 IterBatch 相同，只放大 drain——证明见 v1.1 §4.4。 第三情形例: IterBatch 走 a/b 形态 (k_L1=K) 而合并侧被 512B 推荐值截断时, n_K^m=n_K, 命令数打平 (既不省 b₀ 倍也不放大), 合并仅剩 drain 惩罚 -> 恒劣; 反之若 IterBatch 走 c/d 形态切 K 而合并侧每核命令数更少, 则按实际节省判定。
每核命令数口径 (issue#35): 真实命令数 = 合并组数 × 每组 K 段数 = ⌈b_core/b₀⌉·⌈K/k_L1^m⌉。注意 v1.1 §4.4 "命令数与 IterBatch 相同 = b_core·n_K" 中的 n_K 是未合并粒度 (⌈K/k_L1^iter⌉); 误代入合并后段数 ⌈K/k_L1^m⌉ 会多计 b₀ 倍 (修复前 evaluate 即此错, L1 绑定情形命令时延虚高 b₀ 倍, 可把仲裁方向翻错)。
GM 数据量口径 (issue#31): 各 (合并组, K段) 的数据互不重叠, 每个输入字节恰好从 GM 读一次 —— K 截断与 L1 绑定两种情形的芯片 GM 读取量都 = V_in (末段按实际剩余计, 无 padding 上取)。上式的 T_load 级联只用于刻画命令/双缓冲调度结构: 数据时延按 V_in/W_GM 计, n_K 只放大 DMA 命令项 ⌈b_core/b₀⌉·n_K^m × T_cmd (issue#35 口径)。
5. MergeBatch vs IterBatch 净收益
泛化分界 (issue#35 命令数 / issue#36 搬移效率, 覆盖三种情形): 直接比较两分支实际每核 DMA 命令数与效率加权搬移时延 ——
\text{净收益} = \underbrace{(cmds_{iter}-cmds_{mb})\,T_{cmd}}_{\text{命令节省}} + \underbrace{(t_{data}^{iter}-t_{data}^{mb})}_{\text{效率节省}} - \underbrace{(b_0-1)(T_{comp}+T_{write})}_{\text{drain 惩罚}},\qquad \begin{array}{l}cmds_{iter}=b_{core}\lceil K/k_{L1}^{iter}\rceil\\ cmds_{mb}=\lceil b_{core}/b_0\rceil\lceil K/k_{L1}^m\rceil\end{array}
其中效率节省来自合并 tile 放大 (t_data 按 eff(tile) 加权, 见 §4)。T_cmd=0 时命令节省为 0, 效率节省依然在项 —— MergeBatch 凭搬移效率胜出 (用户澄清口径)。K 截断且效率打平 (两侧 tile 均 ≥16KB 饱和) 且 T_cmd>0 时严格退化为 v1.1 §4.5 闭式 b_core > b₀(T_comp+T_write)/T_cmd；L1 绑定理想情形 (k_L1^m=k_L1^iter/b₀ 且 tile 均饱和) 命令数与效率均打平、净收益恒负。大 B（b_core 大）且小 MN（T_comp 小、IterBatch 单 batch tile 小未饱和）时 MergeBatch 最优。T_cmd 的物理成因：Nd2Nz 描述符配置（7 字段写 DMA 寄存器）+ 地址生成 + 突发启动 + L1 同步握手 (待 msProf 标定后恢复非零取值)。
6. 与源码的差异（v1.1 §5.1）
源码 MergeBatch 进入条件偏宽——缺搬移量/tile 大小/算存比三条约束，可能把计算 Bound 的 case 误捕获（冗余计算成为新瓶颈）。本软件以理论 5 条件为准。