v0.91: 同步HTML

BMM算子优化分析_Release/BMM算子优化分析_v0.91.html

@@ -170,11 +170,27 @@ $$</div>
 <p>   K 截断时 MergeBatch 的 $k_{L1}$ 不减半 → 每分块计算量 $b_0^2$ 倍（而非 $b_0$ 倍）→ drain 惩罚更大。小 MN 时 $T_{comp}$ 小 → penalty 小 → MergeBatch 更容易赢；大 B 时 $b_{core}$ 大 → 边界节省多 → MergeBatch 更容易赢。</p>
 <p>   条件 1（$b_{core} \ge 2b_0$）是该分界在典型 $T_{bd}$ 下的保守近似。精确边界依赖 $T_{bd}$ 实测标定。</p>
 <p>   **$T_{bd}$ 的物理成因**（batch 边界处硬件必须完成的固定动作）：</p>
+<p>   从 IterBatch 的 kernel 侧源码（<code>cmct/block/block_mmad_iterbatch.h</code>）可直接观察到 batch 边界的 Set/Wait 同步序列：</p>
+<pre><code>   // 当前 batch 最后一个 K 分块结束后：
+   SetFlag&lt;M_FIX&gt;(l0cEventID_ &amp; 0x1);     // Cube → fixpipe: "L0C 可以排空"
+   WaitFlag&lt;M_FIX&gt;(l0cEventID_ &amp; 0x1);    // 等 fixpipe 确认开始 ← 串行握手，不可掩盖
+   CopyOut(cTensor, c1Local_[...]);        // fixpipe 排空 L0C
+   SetFlag&lt;FIX_M&gt;(l0cEventID_ &amp; 0x1);     // fixpipe → Cube: "L0C 已空"
+   // 下一 batch 第一个 K 分块：
+   WaitFlag&lt;FIX_M&gt;(l0CEventID_ &amp; 0x1);    // 等 L0C 可用（被 L0C 双缓冲掩盖）</code></pre>
+<p>   $T_{bd}$ 由三个部分组成：</p>
 <ol class="tight">
-<li><b>Fixpipe 重配置</b>：每 batch 输出写往 GM 不同地址区域，fixpipe 需重配目标地址、步长等寄存器——每次排空的固定设置开销；</li>
-<li><b>L0C 缓冲区切换握手</b>：L0C 双缓冲——Cube 往一半写、fixpipe 从另一半读。batch 边界处 Cube 须等 fixpipe 的 unitflag 确认已开始读当前半区，才能往另一半写新 batch 的部分和——同步握手有固定延迟；</li>
+<li><b>Fixpipe 启动握手</b>（<code>WaitFlag&lt;M_FIX&gt;</code>）：fixpipe 从收信号到启动排空的延迟——地址/步长寄存器重配置（每 batch 输出写往 GM 不同区域）。<b>串行、不可掩盖</b>，是 $T_{bd}$ 的主要成分；</li>
+<li><b>L0C 缓冲区切换</b>（<code>WaitFlag&lt;FIX_M&gt;</code>）：L0C 双缓冲——Cube 写一半、fixpipe 读另一半。被双缓冲掩盖，不贡献 $T_{bd}$；</li>
 <li><b>Cube 流水线重建</b>：systolic array 在新 batch 首个 K 分块时需重新填充——fill 开销与 tile 尺寸无关，是固定成本。</li>
 </ol>
+<p>   <b>证据来源</b>：</p>
+<table><tr><th>证据</th><th>文件</th><th>内容</th></tr>
+<tr><td>MMAD→Fixpipe 同步开销存在</td><td><code>CANN社区版9.2.0-beta.1/02_API参考/AscendC_API/180_..._UnitFlag.md</code></td><td>"未开启UnitFlag功能时，MMAD和FIXPIPE是指令级别的同步……流水串行"；实测 7.3% 改善（M=128,N=30720,K=64）</td></tr>
+<tr><td>同步指令是高开销指令</td><td><code>CANN社区版9.2.0-beta.1/01_AscendC算子开发/260_..._SIMT算子性能优化.md</code></td><td>"除法、取模、<b>同步</b>、原子操作等都属于<b>高开销指令</b>"</td></tr>
+<tr><td>编译器默认插入同步指令</td><td><code>CANN社区版9.2.0-beta.1/01_AscendC算子开发/048_..._算子编译基本用法.md</code></td><td>"默认会插入内存同步指令……这些同步指令<b>会带来性能开销</b>"</td></tr>
+<tr><td>同步机制是架构级关注点</td><td><code>00_硬件/昇腾950_NPU架构白皮书.pdf</code> §4.1.6</td><td>新增 BufferID 同步机制替代 set_flag/wait_flag——"降低了同步的复杂度"</td></tr></table>
+<p>   $T_{bd}$ ≈ fixpipe 启动握手延迟（寄存器写入 + DMA 启动），量级估计为数十 ns。知识库未给出精确数值，需实测标定。</p>
 <p>   这些开销<b>与 batch 的计算量无关</b>，是每次 batch 切换的固定成本。大 batch 时被大量计算分摊，占比可忽略；小 batch 时每个 batch 绝对时延短，边界开销占比显著。MergeBatch 把 $b_0$ 个 batch 并为一次大矩阵计算，边界数降 $b_0$ 倍——<b>这是 MergeBatch 的结构性收益来源</b>。</p>
 <p>   <b>MergeBatch vs IterBatch 优势总结</b>：</p>
 <table><tr><th>维度</th><th>IterBatch</th><th>MergeBatch</th><th>差异来源</th></tr>