移动 req.txt（本地最新版）到 BMM/ 目录
This commit is contained in:
312
BMM/req.txt
Normal file
312
BMM/req.txt
Normal file
@@ -0,0 +1,312 @@
|
||||
|
||||
《ASW_Basic分支分析_v1.4》文档 还是有欠考虑的地方
|
||||
1、在“五、实现方案”中，目前的结论都是 SingleCoreM/N 、BaseM/N是正方形 感觉有问题，尤其是 要求 SingleCoreM/N 为正方形，如果 M=2048、N=512，如果B不算太小，在L1能放下的条件下，SingleCoreN=512，此时SingleCoreM=2048或1024肯定比SingleCoreM=512要好，此时每Batch重复读更少了，但此时 SingleCoreM/N就不是正方形了，推导上到底是哪里出了问题？
|
||||
请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，请进一步修正完善《ASW_Basic分支分析_v1.4》文档，还是以markdown和html格式交付，并同步到仓库
|
||||
-------------------------------------------
|
||||
|
||||
《ASW_Basic分支分析_v1.3》文档 还是有欠考虑的地方
|
||||
1、在“五、实现方案”中，“BaseM/N 的具体确定过程”为什么要BaseK≥ 128B/dtype（最小高效粒度）? 我们说的高效搬移是GM->L1，不是L1->L0，L1->L0只有满足Cube的计算粒度就行了，是为了防止Cube计算利用率太低，不是针对高效搬移的，我再强调一下主要搬入瓶颈在GM->L1，不是L1->L0（这段可以被GM->L1或Cube计算掩盖）
|
||||
2、在“5.2 SingleCoreM / SingleCoreN 的确定”中，SingleCoreM/N 的长宽比跟随 M/N 没说清楚理由，“跟随 M/N 使两侧搬移量均衡、避免一侧搬移过大成为 GM 带宽瓶颈” 这个对实际GM->L1搬入时延的减少到底如何提现？请建模并公式推导，说清楚理由，也可以举例说明，我需要判断下你的理由是否成立
|
||||
请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，基于《ASW_Basic分支分析_v1.3》文档 请进一步修正完善《ASW_Basic分支分析_v1.4》文档，还是以markdown和html格式交付，并同步到仓库
|
||||
|
||||
-------------------------------------------
|
||||
|
||||
《ASW_Basic分支分析_v1.3》文档 还是有欠考虑的地方
|
||||
1、关于 “五、实现方案” 中对于“BaseM/BaseN 的长宽比跟随 SingleCoreM/SingleCoreN（进而跟随 M/N），对齐 16 的倍数。长宽比跟随。。。”的说法存在质疑，当前核内L1->L0的搬移效率是很高的，目前没有建模L1->L0的搬入时间，主要搬入时间在GM->L1上，长宽比跟随是否有利于GM->L1的高效率搬移提升要重点分析下；而且L0A和L0B大小相等，如果使用长宽比跟随的切法，L0A和L0B的容量的使用率就会存在明显差异；基于上述分析，长宽比跟随的切分方法还站得住脚吗？请仔细分析下
|
||||
请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，请进一步修正完善《ASW_Basic分支分析_v1.3》文档，还是以markdown和html格式交付，并同步到仓库
|
||||
-------------------------------------------
|
||||
|
||||
《ASW_Basic分支分析_v1.2》文档 还是有欠考虑的地方
|
||||
1、在 “5.2 SingleCoreM / SingleCoreN 的确定（每核输出 tile，≥ BaseM/N）”中，如果M\N确定，那么SingleCoreM/N 越小，总块数 mCnt×nCnt 越多，核间重复读会越多，此影响是否有分析？
|
||||
2、 在“5.1 BaseM / BaseN 的确定”中说"“BaseM/BaseN 的长宽比跟随 SingleCoreM/SingleCoreN（进而跟随 M/N），对齐 16 的倍数”，这个是为什么？为什么长宽比要跟随？
|
||||
请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，基于《ASW_Basic分支分析_v1.2》文档 请进一步修正完善《ASW_Basic分支分析_v1.3》文档，还是以markdown和html格式交付，并同步到仓库
|
||||
-------------------------------------------
|
||||
《ASW_Basic分支分析_v1.2》文档 还是有欠考虑的地方
|
||||
1、关于其尾轮切分问题，如果是算力Bound，尤其是算力Bound特别严重时，这时访存效率是次要因素了（至少dValue可以放宽至128Byte，tile_size至少也可以放宽一半吧），尾轮也要把核都用满，这样所有核才能都发挥出算力，以求尽快算完
|
||||
2、《ASW_Basic分支分析_v1.2》文档 整体的结构审视一下是否合理，是否需要调整，包括全文的逻辑连贯性、一致性，这个是期望当做独立文章发表的
|
||||
|
||||
-------------------------------------------
|
||||
《ASW_Basic分支分析_v1.2》文档 ，不要引用 “v0.98...”，直接把 搬移效率 问题 在本文前面解释下，这是篇独立文章，只能引用有网上链接的公开网页内容，不能引用本地文件;而且你对 硬件最低要求 dValue ≥ 256B 这句话理解有误，这个dValue是矩阵为ND数据排布是连续排布的列数据量(Byte)，不会是K维度和N维度的乘积，对于ND排布的右矩阵，如果是非转置dValue最大就是N*dtype，如果是转置dValue最大就是K*dtype
|
||||
-------------------------------------------
|
||||
《ASW_Basic分支分析_v1.2》文档 在 5.2 尾轮重切时说的 重切约束 是怎么来的？怎么跟 BMM算子优化分析_v0.98 文档中 搬移效率的要求感觉对不上呢？“*最优切分因子*：在不违反约束的前提下尽量让 r*s接近C”,这里的“约束”就是“重切约束”吗？
|
||||
|
||||
-------------------------------------------
|
||||
《ASW_Basic分支分析_v1.1》文档还是有几个问题：
|
||||
1、在 5.3 尾轮影响的量化 中 你提到 n_wave>=4 ，尾轮影响才小于25%，这个25%已经是很大的影响了，而2轮、3轮的case应该不在少数，这些情况要如何提升性能呢？要得是最优实现，要算子总时延最短，此时是否再进行尾轮切分？要如何切分？结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，给出最优实现的公式推导；注意尾轮切分是在host(CPU)上做的,是算子启动前提前算好的，从host下发给device(NPU)，不占用NPU时间
|
||||
2、在 六、实现方案 中也没有说清楚如何确定BaseM、N, singleCoreM、N，是16的倍数遍历吗？要结合尾轮处理一起描述具体实现过程；另外和源码的差异是什么要讲清楚
|
||||
请基于v1.1进一步修正完善生成《ASW_Basic分支分析_v1.2》文档并同步到仓库
|
||||
|
||||
-------------------------------------------
|
||||
|
||||
《ASW_Basic分支分析_v1.1》中的step0一定要让L0C开乒乓吗？Ascend950PR芯片的fixpipe有unitflag功能，如果打开可以没完成16*16*16的矩阵乘计算就立即写出，这样是不是可以L0C不开double buffer就达到很好的性能，BaseM/N也可以更大，mCnt和nCnt会更小，重复读会更少，我把BMM源码拷贝到了：/storage/Users/currentUser/OpenDesk/Matmul算子分析/.opendesk/matmul/batch_mat_mul_v3 ，你一定要比对源码分析，结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，请进一步修正完善《ASW_Basic分支分析_v1.1》文档并同步到仓库
|
||||
|
||||
-------------------------------------------
|
||||
《BMM算子优化分析_v0.98》文档的第八章是至关重要的一章，把这一章单独领出来写成一篇文档，当前《BMM算子优化分析_v0.98》文档的第八章还是有问题的，有欠考虑
|
||||
1、你定义的mCnt和nCnt是一个Batch内的M、N维度切分个数是吗，“约束 1——并行度下限：总块数须填满 C 核。” 这个约束为什么写成mCnt*nCnt>=向上去整的C/B，而不是B*mCnt*nCnt %C = 0 ？
|
||||
2、如果 B*mCnt*nCnt %C 不等于 0，有余数，那可能在处理多轮分块后存在尾轮问题，那尾轮需要重新切分把核用满吗？还是尾轮和之前轮的SingleCoreM、SingleCoreN、BaseM、BaseN一样？如果尾轮单独切分应该怎么切分？
|
||||
请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，基于《BMM算子优化分析_v0.98》文档的第八章把ASW_Basic这个兜底分支单独好好写一篇理论最优方案的实现分析，还是以markdown和html格式交付，最后要同步到gitea仓库上去
|
||||
|
||||
-------------------------------------------
|
||||
|
||||
《BMM算子优化分析_v0.97》文档的第八章是至关重要的一章，大量BMM的case都在这一章，一定要把最优实现的具体方案分析的非常透彻清楚，为什么先按B分组再切M、N不优？是任何情况都不优吗？L2容量能放下读写数据也不优吗？先有时延建模，然后最优方案的一步步做法要有清晰的逻辑推导，可以分场景不同情况讨论，每一步要确实可实现，多用公式描述，公式里涉及的变量和维度一定要标注清楚，请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，基于v0.97修改完善生成v0.98，还是以markdown和html格式交付，最后要同步到gitea仓库上去
|
||||
|
||||
------------------------------------------
|
||||
《BMM算子优化分析_v0.96》文档的第八章没有说明清楚具体如何按 B→M→N 优先级分配到 C 核，我的初步想法是先按B分组，例如4个B，那就8个核一组，组内再切MN，这样重复读只会发生在这8个核，这样会不会更好？但是也存在B不能被核数整除的情况应该怎么办？如果不是按B先分组，那具体应该如何按 B→M→N 优先级分配到 C 核呢？请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，基于v0.96增量修改完善生成v0.97，还是以markdown和html格式交付，最后要同步到gitea仓库上去
|
||||
|
||||
------------------------------------------
|
||||
《BMM算子优化分析_v0.96》文档的第八章怎么没有？有些内容缺失了、有些内容和第七章混到一起了啊？？改进修正，另外第八章ASW_Basic的具体实现方案要好好梳理清晰，结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，注意描述逻辑一定要连贯、要严谨，最后要同步到gitea仓库上去
|
||||
|
||||
-----------------------------------------
|
||||
将MergeBatch和IterBatch的各自理论最优实现、对比分析、适用分界、各自与源码对比抽出来，新整理成一篇文档，如果涉及文章或源码引用必须使用官网链接，不能引用本机文件夹或文件
|
||||
-----------------------------------------
|
||||
|
||||
《BMM算子优化分析_v0.95》文档的MergeBatch的理论最优实现的思路可能有点问题，应该是
|
||||
1）基于L0C容量约束、算存比约束确定最大合并数b，或者叫b0
|
||||
2）基于b0和L0A、L0B确定kL0
|
||||
3）令bL1_=b0，基于L1容量，求kL1_， 进而kL1=min(kL1_, K, 512B)
|
||||
4）基于kL1和L1容量确定bL1，力求bL1尽量大
|
||||
请基于上述建议，基于v0.95文档修改MergeBatch分支中相关章节和描述升级到v0.96，注意描述逻辑一定要连贯、要严谨，最后要同步到gitea仓库上去
|
||||
|
||||
-----------------------------------------
|
||||
|
||||
升级一下《BMM理论vs源码对比分析_v1.0》文档，重点对比分析下 ASW_Basic 分支的理论最优实现和源码实现的差异，升级到v1.1，v1.0也要保留不要删除；理论最优实现参考《BMM算子优化分析_v0.95》，源码实现参考/storage/Users/currentUser/WorkBuddy/昇腾NPU/昇腾NPU知识库/代码仓/ops-nn/matmul/batch_mat_mul_v3 中的对应源码实现
|
||||
|
||||
-----------------------------------------
|
||||
|
||||
BMM算子优化分析_v0.95的文档中 ASW_Basic 分支还需要优化：
|
||||
1、在实现方案Step0中描述的baseK*dtype>=256Byte,这个在L1->L0搬移时并不是必要条件，第二章的搬移效率主要是GM->L1的dValue要求，应该是每次GM->L1的那个K维度的数值kL1*dtype>=256Byte，实际上如果核间不切K，K=singleCoreK>=kL1>=BaseK
|
||||
请基于上述建议修改v0.95文档ASW_Basic 分支中相关章节和描述，注意描述逻辑一定要连贯、要严谨，最后要同步到gitea仓库上去
|
||||
|
||||
-----------------------------------------
|
||||
|
||||
BMM算子优化分析_v0.94的文档中还是有一些需要优化
|
||||
1、ASW_Basic 分支 的 实现方案 的Step0，没有考虑SingleCoreM>=BaseM, SingleCoreN>=BaseN，而且BaseM、BaseN要受制于L0的约束，BaseM、BaseN要尽量把L0C用满，要把整个ASW_Basic 分支作为整体考虑最优的tiling和swizzle方案的实现，可以分场景描述，请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析
|
||||
2、在MergeBatch 分支 中的 “MergeBatch vs IterBatch 分界建模” 中，对比T_Iter和T_Merge时，只考虑了 K 截断情形，n_k=1，那对于kL1<K呢？n_k>1呢，这时的分界条件是什么？缺乏有逻辑的分析，请补充完善分析
|
||||
请基于v0.94文档增量撰写修改优化v0.95文档，还是以markdown和html格式交付，注意逻辑一定要连贯、要严谨，最后要同步到gitea仓库上去
|
||||
|
||||
-----------------------------------------
|
||||
|
||||
BMM算子优化分析_v0.94的文档中 ASW_Basic 分支 还是没讲清楚，你为什么直接用L0去约束SingleCoreM、SingleCoreN，这样合适吗？在TCubeTiling结构体成员变量概念里面，BaseM、BaseN会直接受制于L0的容量约束，但是SingleCoreM、SingleCoreN并不是受制于L0，SingleCoreM、SingleCoreN更重要的是影响量GM->L1的搬移效率和重复读数据量，要把整个ASW_Basic 分支作为整体考虑最优的tiling和swizzle方案的实现，可以分场景描述，请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，请基于上述建议修改v0.94文档ASW_Basic 分支中相关章节和描述，注意描述逻辑一定要连贯、要严谨，最后要同步到gitea仓库上去
|
||||
|
||||
-----------------------------------------
|
||||
|
||||
BMM算子优化分析_v0.94的文档中 ASW_Basic 分支 还是没讲清楚啊，具体实现怎么做啊，SingleCoreM、SingleCoreN怎么确定啊？请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，请基于上述建议修改v0.94文档ASW_Basic 分支中相关章节和描述，注意描述逻辑一定要连贯、要严谨，最后要同步到gitea仓库上去
|
||||
|
||||
-----------------------------------------
|
||||
|
||||
BMM算子优化分析_v0.94的文档中 ASW_Basic 分支 的 L2切分讲的不好，尤其是 场景 C，没有讲清楚 ，当S_in>L2容量时，还是不要基于mL2、nL2这样的概念来描述，这个概念理解会有偏差，我默认会把mL2理解成L2中的M维度上的切分长度，而且不是切分块数，L2主要是cache，不能完全当buffer用，软件可控粒度比较粗，可以定义输入tensor从GM读的时候驻留L2，输出tensor写到L2，描述时还是基于 TCubeTiling结构体 中的概念来组织语言描述，L2上要放多少SingleCoreM、SingleCoreN，这些SingleCoreM、SingleCoreN组成的分块要如何swizzle，请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，请基于上述建议修改v0.94文档ASW_Basic 分支中相关章节和描述，注意描述逻辑一定要连贯、要严谨，最后要同步到gitea仓库上去
|
||||
|
||||
----------------------------------------
|
||||
|
||||
BMM算子优化分析_v0.93的文档中 ASW_Basic 分支 的 L2切分讲的不够清楚，尤其是 场景 C ，当S_in>L2容量时，mL2,nL2应该怎么确定？mL2,nL2和mL1, nL1是不是应该相等，请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，补充给出ASW_Basic分支的最优tiling和swizzle方案，基于v0.93增量完善生成v0.94，还是以markdown和html格式交付，注意逻辑一定要连贯、要严谨，最后要同步到gitea仓库上去
|
||||
|
||||
----------------------------------------
|
||||
|
||||
现在需要新写一篇文档，对比下 《BMM算子优化分析_v0.93》文档的理论最优实现方案分析和 在“/storage/Users/currentUser/WorkBuddy/昇腾NPU/昇腾NPU知识库/代码仓/ops-nn/matmul/batch_mat_mul_v3” 算子的当前源码实现，每个分支逐一对比，各分支条件及其tling&swizzle实现、以及如何修改源码来实现理论最优方案，每个分支的对比都要总结分析下差异和优劣，理论分析的最优方案究竟是不是最优，当前源码的实现原理又是什么源码是否是合适的，还是以markdown和html格式交付，注意逻辑一定要连贯、要严谨，最后要同步到gitea仓库上去
|
||||
|
||||
----------------------------------------
|
||||
|
||||
BMM算子优化分析_v0.92的文档中 的 “MergeBatch vs IterBatch 分界” 里面有些理解有问题
|
||||
1、对于T_iter和T_merge的建模，由于L0C是开了double buffer的，因此fixpipe和cube之间就没有额外的同步开销，T_bd应该不存在
|
||||
2、MergeBatch的实现核心是多个Batch Merge一起搬移GM->L1，而不仅是多个Batch Merge一起计算，同样的IterBatch是逐个Batch的搬移和计算，这个点是MergeBatch和IterBatch的核心差异
|
||||
请基于以上两点修改，并结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，核心目标是找清楚MergeBatch和IterBatch的适用条件边界，并论述清楚，证据要确凿，逻辑要严谨，请基于v0.92文档修改优化撰写v0.93文档，还是以markdown和html格式交付，注意逻辑一定要连贯、要严谨，最后要同步到gitea仓库上去
|
||||
|
||||
----------------------------------------
|
||||
|
||||
BMM算子优化分析_v0.91的文档中 的 StreamK 分支
|
||||
1、进入分支条件的P是不是应该<=C/2 ?
|
||||
2、gridK是不是就等于 C/P ? 这个girdK应该如何取值要说明清楚
|
||||
3、在 “K 闭式阈值推导” 时 说 “ $M^t N^t/(M^t+N^t)$ ~ O(100)” 这是为什么？如何得到的，要解释下
|
||||
请基于v0.91文档修改优化撰写v0.92文档，还是以markdown和html格式交付，注意逻辑一定要连贯、要严谨，最后要同步到gitea仓库上去
|
||||
|
||||
----------------------------------------
|
||||
|
||||
BMM算子优化分析_v0.91的文档中 “MergeBatch vs IterBatch 分界”里面还需要优化调整一下，
|
||||
1、请把一阶二阶建模合一起描述，先讲下建模方法原理，再一起写公式，不要分一阶二阶分开写，
|
||||
2、对于分界条件penalty对应的两个式子需要分别解释下，什么叫“L1绑定”，什么叫“K截断”，跟前面的推导又有什么关系
|
||||
3、在证据来源里面，你在“同步指令是高开销指令”中引用了“CANN社区版9.2.0-beta.1/01_AscendC算子开发/260_..._SIMT算子性能优化.md”文的，这个文档应该是讲AIV核的，BMM算子执行在MergeBatch和IterBatch的时候没有用到AIV核吧，源码有证据用到AIV核了吗？
|
||||
请优化调整 BMM算子优化分析_v0.91的文档
|
||||
|
||||
---------------------------------------
|
||||
|
||||
在“/storage/Users/currentUser/WorkBuddy/昇腾NPU/昇腾NPU知识库/代码仓/ops-nn/matmul/batch_mat_mul_v3” 算子的MergeBatch和IterBatch的kernel侧源码中，是否有硬件间的Set\Wait操作？能否从这个角度分析T_bd存在的原因，请结合NPU知识库的其他资料说明
|
||||
|
||||
---------------------------------------
|
||||
|
||||
源码用 MIN_BATCH_L0=4，也不是代表开了4buffer，只是L0里一次放4batch，我早就说了源码未必最优，这个仅供参考，我现在是让你找“T_bd的物理成因能否在 NPU资料库中找到对应证据？”，尤其要在 “昇腾950_NPU架构白皮书.pdf”和“/storage/Users/currentUser/WorkBuddy/昇腾NPU/昇腾NPU知识库/CANN社区版9.2.0-beta.1/01_AscendC算子开发”里面找
|
||||
|
||||
---------------------------------------
|
||||
|
||||
BMM算子优化分析_v0.91的文档中 MergeBatch vs IterBatch 分界中说到的 “每 batch 边界有固定开销”，这个固定开销是什么？为什么有这个固定开销要解释下，分析后要总结下MergeBatch相对于IterBatch的优势是什么
|
||||
|
||||
---------------------------------------
|
||||
|
||||
BMM算子优化分析_v0.91的文档中 MergeBatch vs IterBatch 分界建模 中有些概念还是交代的不清楚
|
||||
1、一阶流水模型 中的分块是什么概念？什么维度？BMKN分别怎么切，要介绍下，对应的，后续公式中提到的符号都要介绍下
|
||||
2、MergeBatch的条件2到条件5去推导条件1的分析过程没有看到
|
||||
请你请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，尽量多用公式推导，细化 MergeBatch vs IterBatch 分界建模 的分析过程，核心目标是找清楚MergeBatch和IterBatch的适用条件边界；进一步完善BMM算子优化分析_v0.91的文档
|
||||
|
||||
--------------------------------------
|
||||
|
||||
既然你说一阶流水模型下MergeBatch 始终不优于 IterBatch，那就说明一阶流水模型找不到MergeBatch和IterBatch的适用分界条件，那你能不能通过建模二阶模型进一步分析，以明确找清楚MergeBatch与IterBatch的分界条件？如果MN较小时，MergeBatch多batch一起做可以把L0C用满，IterBatch此时就用不满，这会让MergeBatch在某些条件下取得优势吗？当B很大时，MergeBatch会先以b0为粒度进行乒乓流水，只有最后一个b0才可能进一步切K做double buffer乒乓流水；另外我在补充下，在无业务实测搬移效率时，还发现数据量越大搬移效率越高，即单核搬移数据总量越大、单块数据量越大搬移效率会越高，大数据块连续搬移比离散搬移效率高；请你请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，尽量多用公式推导；核心目标是找清楚MergeBatch和IterBatch的适用条件边界；
|
||||
基于v0.9增量写v0.91文档，还是以markdown和html格式交付，注意逻辑一定要连贯、要严谨，最后要同步到gitea仓库上去
|
||||
|
||||
-------------------------------------
|
||||
|
||||
BMM算子优化分析_v0.9的文档中有个问题需要解答：
|
||||
是关于MergeBatch和IterBatch的适用边界问题，MergeBatch好像都能用IterBatch来做，具体什么条件MergeBatch才相对IterBatch更有优势呢？
|
||||
我初步感觉是，如果是每Batch都是计算Bound，那肯定用IterBatch，因为MergeBatch会浪费算力，IterBatch不会，此时IterBatch时延更短。在访存Bound时，MergeBatch和IterBatch都是 先搬移数据时延+最后一小段不可掩盖的计算时延+最后一小段不可掩盖的搬出时延，如果B较小，用MergeBatch做最后一个b0的时候，只能切K来乒乓，最后一段kL0的计算时延无法被掩盖，由于MergeBatch的实现天然会浪费算力和计算时延会更多，此时如果用IterBatch来做，虽然最后kL0的计算时延也无法被掩盖，但是IterBatch的做法不会浪费算力，同样维度计算下计算时延会更小，这使得IterBatch总时延会更短，而且由于B较小，最后不可掩盖的计算时延不可忽略，这段不可掩盖的计算时延在总时延中的占比会更高；如果B较大，MergeBatch和IterBatch也都是 先搬移数据时延+最后一小段不可掩盖的计算时延+最后一小段不可掩盖的搬出时延，但是此时，最后不可掩盖的计算时延占比会较低，这段不可掩盖的计算时延在总时延中的占比会更低，前面的数据搬移时延占比会更高，MergeBatch在大B情况下，可以切K然后多个B一起搬移，带宽搬移效率会更高；关于带宽搬移效率分析结论参考第二章；
|
||||
例如尝试把问题具象一些：MergeBatch的分支条件2~5是相对明确的，但是条件1不一定对，缺少清晰的推理或证明，尽量多用公式推导，假设输入的BMM的shape和dtype(16bit)是确定的，请你请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，先用公式和逻辑建模MergeBatch分支做的算子端到端时延t1，也建模IterBatch分支来做的时延t2，看看在满足MergeBatch的条件2~5的前提下，能否推导出条件1或类似条件1的结论；
|
||||
核心目标是找清楚MergeBatch和IterBatch的适用条件边界
|
||||
|
||||
-------------------------------------
|
||||
|
||||
在 BMM算子优化分析_v0.9的文档中对于StreamK分支的“归约代价可接受”中，和T_SK对比的T_PIPE=max(T_MTE2, T_MMAD)，这里T_MMAD=2MKN/Q_16，为什么直接就按单Batch的M、K、N维度来估算计算时延以及随后的访存时延？如果不切K，只切B、M、N到每个核都是做1Batch吗？这里缺少了降核ASW的芯片级维度到核级维度的说明，应该是芯片级时延 T_SK < T_PIPE，请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，修改v0.9文档，增加字数一定不要太多，不要加一堆不痛不痒的描述解释，用公式清晰表达逻辑关系，内容要精且清晰，还是以markdown和html格式交付，注意逻辑一定要连贯、要严谨，最后要同步到gitea仓库上去
|
||||
|
||||
--------------------------------------
|
||||
BMM算子优化分析_v0.9的文档中 MergeBatch中新增的 b_core=2的解释 中说“但 MergeBatch 引入了 50% 冗余算力——一旦 tile 内 K 段过短导致计算暴露，性能退化”这句不理解，请稍微展开解释下
|
||||
--------------------------------------
|
||||
|
||||
BMM算子优化分析_v0.8的文档中还有一些需要优化的
|
||||
1、streamK分支的进入分支条件的第3点直接放在进入分支条件汇总里面是不是不合适，毕竟T_pipe也是无法预设的，汇总的条件要直接基于case（B、M、K、N和dtype）和芯片规格参数能直接判断，具体原理推导和公式放到逐条解释说明里，streamK分支的进入分支条件的第3点的逐条解释的推导也看不懂，K的闭式阈值是怎么推导的，为什么访存Bound的阈值更低？请补充详细公式列出推导过程，并说明理由
|
||||
2、对于MergeBatch的进入分支条件的第一个条件有人挑战说b_core=2即b0也可以进行MergeBatch，为什么一定要乒乓,我之前初步认为如果b_core=2按IterBatch做乒乓有一定流水掩盖，时延会比MergeBatch好，但是如果MN较小，在b_core=2时，到底是MergeBatch好还是IterBatch好？请补充分析下加在MergeBatch分支章节里面
|
||||
请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，基于v0.8增量写v0.9文档，增加字数一定不要太多，不要加一堆不痛不痒的描述解释，内容要精且清晰，还是以markdown和html格式交付，注意逻辑一定要连贯、要严谨，最后要同步到gitea仓库上去
|
||||
|
||||
----------------------------------
|
||||
|
||||
BMM算子优化分析_v0.8的文档中的StreamK分支进入条件解释的合理性还需要仔细审视，在“归约代价可接受”中的公式中描述的Q16，Q_AIV都是什么意思？θ_c=11是如何具体计算出来的？以及随后的“工程约束”的解释就更粗糙了，怎么就得到源码中的8192是为了摊薄固定开销？逻辑是原理什么？请结合NPU架构和BMM算子执行数据流过程、逻辑合理性仔细审视分析，并修改完善v0.8文档，最后要同步到gitea仓库上去
|
||||
|
||||
---------------------------------
|
||||
|
||||
BMM算子优化分析_v0.7的文档中的StreamK分支里面在进入分支条件中解释归约代价可接受时说Tmmad>α*Treduce,α=10才能保障流水不改变瓶颈归属，为啥是α=10，为啥不是α=1？而且也没有跟读入时延比较，这样合理吗？请结合NPU架构和BMM算子执行数据流过程仔细审视分析，分析结果如果影响文档中其他地方也需要修改，如果改动较大，请基于 BMM算子优化分析_v0.7文档 改造到v0.8，字数一定不要多，不要加一堆不痛不痒的描述解释，内容要精且清晰，还是以markdown和html格式交付，注意逻辑一定要连贯、要严谨
|
||||
|
||||
------------------------------
|
||||
|
||||
BMM算子优化分析_v0.6文档 还有一些问题：
|
||||
1、文档中不要说 “基于 issue#3 扩展。”
|
||||
2、芯片算存比的计算R16为什么是 486*2/1.6，这个2是啥？不需要这个2，因为486这个标称算力已经是包含乘和加2次运算后的了，包括后续涉及的对应计算逻辑都要对应修正
|
||||
3、IterBatch 分支 的进入条件3.c和3.d我没有想清楚，是不是合并成3.c一条就行了，只把现在3.c的b_per_core=1改成b_per_core>=1，请仔细帮忙审视下是否合理，3.d原本是想说对于某些每核分到的batch有2个或以上但是L1又放不下一整个batch的左右矩阵，应该符合什么条件才适合流水掩盖，请帮忙仔细考虑清楚并进行必要修正及补充
|
||||
4、对于 StreamK 分支 的第三个进入条件还是不理解，请一步步按实现流程解读清楚，在解释中说到的Treduce主要包含的时延应该是gridK次的读回+AIV的求和+最终结果写回的时延，而且gridK的中间结果也可以占用L2内存，使用L2的读带宽读回AIV核累加，AIV是独立硬件，芯片架构上数据流是GM/L2->UB memory->AIV->UB memory->L2/GM，这里的UB memory是AIV核的核内内存，用于承载AIV核的输入输出，相关芯片架构规格可参考（/storage/Users/currentUser/WorkBuddy/昇腾NPU/昇腾NPU知识库）
|
||||
5、在ASW_Basic 分支的L2 切分中介绍的分场景决策的场景 B 中说到，“输入驻留、输出直写 GM”、“保住r_in=1”，这个r_in=1是什么意思？为什么就决定“输入驻留、输出直写 GM”？“输入驻留、输出直写 GM”、“保住r_in=1”的好处是啥？推导逻辑又是啥，论述上都有缺失，请把理由描述清楚；ASW_Basic 分支的L2 切分要首先介绍下是切什么？你说到“块内分配用错位分核（对角线分配）”这块的描述不好理解，能举例并有简单图示配合说明下吗？
|
||||
基于 BMM算子优化分析_v0.6文档 改造到v0.7，字数一定不要多，不要加一堆不痛不痒的描述解释，内容要精且清晰，还是以markdown和html格式交付，注意逻辑一定要连贯、要严谨
|
||||
|
||||
------------------------------
|
||||
|
||||
BMM算子优化分析_v0.6文档还是需要修改优化下，
|
||||
1、关于ASW_BASIC的实现方案的swizzle：ASW 滑窗蛇形章节，举例说明的窗口内没有提现出蛇形，在窗口0的第3块是（μ3,ν0），如果窗口内也是蛇形的话第4块应该是（μ3,ν1）而不是（μ0,ν1），窗口内是不是也很有必要蛇形？如果是请解释并修改对应章节
|
||||
2、关于ASW_BASIC的实现方案的L2 切分（工作集超 L2 时），这个场景描述还是很不细致，逻辑原理也没有说清楚，也没有考虑写出也是会占用L2空间的情况，写出占用L2的话便会压缩L2用于读入数据的空间，如果写出不占用L2的话，直接写出到GM，此时会不会进入fixpipe写出Bound？可能要分场景分别分析，注意借助公式描述清楚核心逻辑原理，找到最优实现方案，并适当举例说明；
|
||||
请基于上述建议修改v0.6文档，字数一定不要多，不要加一堆不痛不痒的描述解释，内容要精且清晰，还是以markdown和html格式交付，注意逻辑一定要连贯、要严谨
|
||||
|
||||
-----------------------------
|
||||
|
||||
针对《BMM算子优化分析_v0.5》文档，发现一些问题需要改进，
|
||||
1、在 符号与芯片参数约定 的表格中，min_TileSize的含义是 确保高带宽利用率的单块搬移数据量最小值，min_DatamountPerCore的含义是 确保高带宽利用率的单核搬移数据量最小值，minCoreNum 是确保高带宽利用率的并行搬移核数的最小值，还有一个概念dValue 含义是单数据块内数据连续排布数据长度（推进256Byte或512Byte，不建议小于128Byte），以上数值是基于Ascend950PR芯片实测分析总结，其重要性核数>单核搬移总数据量>单分块大小>dValue大小，不同NPU芯片数值可能略有差异，文档后续其他描述也要对应审视是否需要调整
|
||||
2、在 符号与芯片参数约定 的表格中，R 含义现在写的是 芯片算存比平衡点（BF16/FP16），与专业语境不太相符，我们一般叫 算存比 或对应位宽算存比， 文档中可以对应就叫 对应位宽算存比，如果是16bit位宽就用R然后下标16表示，文档后续其他描述也要对应审视是否需要调整
|
||||
3、在 符号与芯片参数约定 的表格中，k_thr本意是为了限制进入StreamK分支的最小K值，在batch_mat_mul_v3源码（昇腾NPU知识库/代码仓/ops-nn/matmul/batch_mat_mul_v3）中是AicNum*2048/dtype，为什么是这个数我没搞清楚，可能是个经验值，你可以帮忙分析下补充到StreamK分支中去，文档后续其他描述也要对应审视是否需要调整
|
||||
4、在讲到 实现本质逻辑 时有个表格，其中，切分维度中的 切B 的 读入特征 “每个数据块只被固定的 1 个核读取，核间零重复读”，这个说法没错，但可以补充下，若核内读取每个Batch时单核GM->L1时是切分了M或N再分块完成后续计算，核内也可能存在重复读；包括后面 按切分特征分组 的表格里面，切B的共同特征“零重复读，读写数据量固定” 这个表述也是不准确的，是有条件的，需要对应完善，要进行严谨的描述，配套的其他位置也要对应严谨考虑后修改描述
|
||||
5、在MergeBatch分支的进入分支条件中说 “b0 为单次合并数下限” 可能不够严谨，应该是 “b0 为单次合并计算的batch数下限”，在单核搬移总量的约束中不应该直接写480KB应该写min_DatamountPerCore，毕竟约束条件是可以跨芯片有一定泛化性的，但是480KB的数值是基于Ascend950PR芯片的实测，类似的下面 搬移 tile 大小 的 16KB应该改为min_TileSize，在 访存 Bound（算力浪费可被掩盖）的描述中，“合并把单次计算的算存比放大 b0 倍后仍须低于芯片平衡点 R”,应该是低于对应位宽算存比
|
||||
6、在 IterBatch 分支 的进入条件 L1 容量约束 中说 “只要 L1 放不下单核要处理的完整输入（M、N 维度的 A/B 数据），就会产生跨 batch 的重复读” 这个表述不准确吧，单核逐个batch处理为什么会产生跨batch重复读呢，我认为应该是 如果L1放不下完整维度的M、N（kL1可以小于K,即K维度可切分段放入L1），在计算单Batch时就会产生重复读；
|
||||
7、IterBatch 分支 的 “d) 多 batch 时 (c) 的乒乓版本（容量预算减半）”，我看你只是机械的列出了我原来issue3中的条件，没有任何解释说明？可能你不知道如何解释，这个条件我之前的考虑可能也不成熟，这个条件我之前的想法是，如果平均每核要处理多个batch而L1又无法放下1Batch的左右矩阵，那如何乒乓流水呢？尤其是单核的多个Batch间如何乒乓流水呢？一个思路是还是按Batch乒乓，每个batch只固定预留L1/2的空间和L0C/2，单个Batch的单核计算只切K或者 全载1个切另一个的非K维度，这样单核的Batch间也可以算上一个batch的同时搬入下一个batch，这只是我的初步想法，可能不够成熟，你也好好想想逻辑上有没有漏洞，目标还是为了搬移读入和计算流水掩盖，fixpipe搬出有unitflag，开启unitflag后每算完16x16x16就会硬件自动搬出，所以可以认为搬出的流水是硬件自动完成了，但是单核batch间的读入和计算如何掩盖？尤其是上一个batch在做最后一个分块时，下一个batch能搬入吗？搬入什么样的分块？上一个batch的计算能不能不要产生气泡；注意此时搬移效率也必须要高。还是说条件(c)和(d)其实可以合并，就可以很好的流水掩盖了？这个点我没想清楚，请帮我从硬件流水实现角度仔细考虑完善；考虑清楚后也需要对应适当完善IterBatch的实现部分；
|
||||
8、StreamK 分支 的进入条件的第一个 “并行缺口存在（B/M/N 用尽仍填不满核）” 这个初衷是没问题，但是一般M、N的切分不可能就切到Cube分型的16，那样搬移效率和L0C利用率都太低了，为了图省事往往会粗拍BaseM=256、BaseN=256，但是我们考虑最优实现就不合适只定256了，我想P=B*(M*N*L0C_ElementDtype)/L0C_Size来作为不切K的最大并行度估计可能是合适的，免去了要先去估计一个M、N的切分，以L0C最大利用率来估计如果不切K的并行度，你说呢；进入条件的第二点，K足够长的思路也没问题，但是如何清晰的量化和充分的理由，要仔细考虑，K/gridK>=256，这个256是什么含义呢？是指影响带宽效率的推进dValue的256Byte吗？对于这个“K 足够长（归约代价可接受）”的第二式的解释也可以再详细些，引出安全系数的公式是怎么来的？安全系数α为什么要10？θ为什么是1.7*10^3?源码中StreamK分支的K好像是要求大于2048*AicNum/dtype，有分析下为什么吗？请结合硬件架构和规格仔细考虑分析下；另外对这个第二式解释的Markdown格式的渲染有问题；
|
||||
9、对于每个分支的 进入分支条件，你先集中汇总一下，汇总的条件不要解释，直接一个个列出各个条件，每个条件应该只有B\M\K\N和芯片规格参数的关系约束，汇总完后再逐条解释
|
||||
10、再增加一个章节，遍历BMM 的 case看看都落在哪个分支，遍历的范围是 B（1~2048）、M（1~10240）、K（1~10240）、N（1~10240），看看按当前的进入条件这些case分别都落在哪个分支
|
||||
请基于上述建议重新生成v0.6文档，字数一定不要多，不要加一堆不痛不痒的描述解释，内容要精且清晰，还是以markdown和html格式交付，注意逻辑一定要连贯、要严谨，另外请稍微整理下仓库文件将v0.4、v0.5、v0.6放到同一个文件夹下，文件夹名可以叫“BMM算子优化分析_Release”
|
||||
|
||||
|
||||
--------------------------------------
|
||||
|
||||
《BMM最优软件实现方案设计.md》的第六章给出了BMM最优性能的4大分支，《BMM分块计算数学公式.html》从公式原理角度给出了分块计算的定义，但是这两个之间还差一层逻辑，就是如何从分块计算+最优实现推导出需要这4大分支呢？请帮我好好思考分析这个问题；另外《BatchMatMulV3算子分支实现分析.html》里面有当前BMM算子实现的分析供参考
|
||||
|
||||
-------------------------------------
|
||||
|
||||
需要补充修正一下，在问题定义里说的BMM 的语义是元素级运算，这个写的很好很清楚，但是我们在NPU上是使用Cube核进行分块矩阵乘的计算，请再补充一个分块矩阵乘的公式及其说明，注意4个维度都可以切，直接补充到《BMM分块计算数学公式.html》、《BMM分块计算数学公式.md》这两个文件里去
|
||||
|
||||
--------------------------------------
|
||||
|
||||
BMM分块计算的本质用数学公式要如何表示？注意4个维度都可以切；你直接输出的公式都是没有渲染的，生成格式规范的markdown文档和html文件输出到本地吧
|
||||
|
||||
-------------------------------------
|
||||
|
||||
《BatchMatMulV3算子分支实现分析.html》文件的第五章逐分支详解的描述不够清晰、不够细致，也没有为什么这么做，为什么设置这个参数，这个参数为什么是这个值的分析，请把第五章好好完善，首先要要把代码实现过程清晰的描述出来，可以配套画一些流程图或架构图，每个分支都要清晰的、详细的描述条件、实现过程、步骤，并进行必要分析为什么这么做；注意参考NPU知识库中的其他资料或者上网搜集其他资料辅助分析
|
||||
|
||||
------------------------------------
|
||||
|
||||
详细分析下NPU知识库中ops-nn/matmul/batch_mat_mul_v3的算子代码实现，为了高性能的实现BMM算子的所有case，当前BMM算子有哪些分支，为什么是这些分支，这些分支具体是怎么实现的？形成html格式的分析说明文档输出到本地，可以参考NPU知识库中的其他资料或者上网搜集其他资料辅助分析
|
||||
tips1：算子软件实现方案设计主要是结合芯片微架构特征和规格，设计分块到各个AiC核上的搬移、计算的tiling和swizzle(所谓swizzle简单说就是分块执行的顺序，以及哪个分块在哪个核上做)
|
||||
|
||||
--------------------------------
|
||||
|
||||
分析还是有漏洞，不够细致
|
||||
1、在6.2的排除规则1中，你说“核间再切 B/M/N 不会增加并行度，只会减少每核的 K 范围”，这句话不理解，当一个case输入后，case本身的B\M\K\N是固定的，只切K分到所有核，和切K又切另外维度分到所有核相比，显然前者的K会切的更小，后者的K会切的更大，对应的K的范围会更大才对吧，怎么会“只会减少每核的 K 范围”呢？例如case的B=4,K=4096，如果只切K，每核分得B=4，K=4096/32=128，如果切K又切B，每核分的B=1，K=512，K变大了啊，中间矩阵写出的次数更少了吧，此时Reduce开销会比只切K时更多吗？
|
||||
注意在做本项目时，在分析思考时，如果有不确定的信息或困惑要多参考知识库(/storage/Users/currentUser/WorkBuddy/昇腾NPU/昇腾NPU知识库)的资料，或者从网上查询，不要局限于当前编辑的文档本身；
|
||||
请进一步完善第六章
|
||||
|
||||
--------------------------------
|
||||
|
||||
分析还是不仔细不完备漏洞很多，还是重点先修改第六章的内容：
|
||||
1、转普通Matmul还叫TO_MUL分支合适吗？当前算子源码中TO_MUL是针对K==1，且只用AIV去计算，跟转普通Matmul意义差别很大，转普通Matmul后只是没有B维度了，如何做最优实现是另一大问题，只是不在当前BMM算子下研究，这个分支是将BMM的case中的某一类问题通过转换的方式借助Matmul的分析优化成果，站在Matmul优化的巨人肩膀上高效实现BMM的case，BMM算子优化分析只关注相对Matmul差异化的case的最优实现
|
||||
2、在第6.1章节，对于分支完备性的分析还有很多欠考虑的地方，ASW_Basic不只是B=1吧，B较小时是不是都可以cover？甚至B较大时，单Batch的输出MN超过L0C的大小，此时ASW_Basic（核间切B\M\N）的性能和IterBatch（核间切B，核内可切M\K\N）的性能究竟哪个好，要如何分辨呢？
|
||||
3、在第6.1章节，你说“不存在第六种独立分支——例如"同时切 K 和 M/N"是 StreamK 与 ASW_Basic 的组合，但可归入 StreamK（核间切 K 后，核内自然切 M/N）”，从完备性角度是可能存在核间同时切 K 和 M/N的，从性能最优角度也可以考虑排除一些分支，但为什么排除掉这个分支需要有充分理由说明，当完备性角度考虑的某个分支明确明显不如性能最优角度的候选分支才可以完全排除，性能最优角度列出的分支应该是完备性角度分支的子集，应该是性能最优角度的全集，即任何case若想达到最优性能必然要按性能最优角度的某个分支中的实现方案实现，如果某些case可以在完备性的某个分支中可达到性能最优则不能排除该分支；你定义的StreamK分支是严格限制只切K吗？核间完全不切B\M\N？那这个分支要要求K必须很大？K多大合适进入StreamK分支？
|
||||
|
||||
-----------------------------
|
||||
|
||||
问题还是很多，没有细致考虑数据块在硬件上流转实现的细节，还是重点先修改第六章的内容；
|
||||
1、按我的设想，还应该有个可转普通Matmul的分支，即当左矩阵或者右矩阵中有一个的B=1即BatchA=1或BatchB=1，则可以把另一个B合并到非K的维度上，例如左矩阵的BatchA=1，此时可以将矩阵变为[M,K]@[K,BatchB*N]这样的二维矩阵相乘，只是输出后要做一个按Batch的split，从而转换普通Matmul的软件实现；
|
||||
2、请先从系统角度分析下为什么是这几个分支？这些分支可以把所有BMM的case都覆盖全面？还有没有其他分支的可能？理由要充分和逻辑要清晰
|
||||
3、第6.3 MergeBatch 不是每次计算都“将单核负责的 全部B_core 个 batch 的 A 矩阵沿 M 维拼接为 [B_core×M, K]、B 矩阵沿 N 维拼接为 [K, B_core×N]，调用一次 Matmul 得到 [B_core×M, B_core×N] 的等效大矩阵”，假设单核分到B_core 个 batch ，Cube->L0C 单次计算时，可以只进行b个batch，b<=B_core，假设L1上放的Batch是bL1，L0上放的是bL0，单次实际计算的Batch数是b，那么b<=bL0<=bL1<=B_core；而且核内计算和搬移时，是可以切K的，切K后进行[bM,kL0]@[kL0,bN]=[bM,bN]，多个K可以在L0C上直接累加得到最终的[bM,bN]再取BlockTrace从L0C搬移输出到L2或GM
|
||||
先基于我上面的提示，进一步完善第六章内容
|
||||
|
||||
----------------------------
|
||||
|
||||
补充几点：
|
||||
1、当前文档有很多描述很不专业，本机有一些昇腾NPU软硬件知识库可参考，路径是 /storage/Users/currentUser/WorkBuddy/昇腾NPU/昇腾NPU知识库
|
||||
2、数据可以直接从GM读取到L1(GM带宽)，在L2是cache配置时会随路驻留在L2，同样的数据下次AIC再需要用的时候如果L2 cache中有就可以命中并以L2的速率读取；L0C可以直接写出到L2，也可以直接写出到GM；注意L2容量有限，而且可能读写数据都会占用L2容量，如果L2容量被占满了，再从GM来读入或从L0C写出新数据时，L2 cache的内容会发生替换，L2腾空间有两个办法，一是对于L2已有的L0C写出的数据要先写回GM(写GM带宽)才能腾出空间，二是对之前从GM读入的在L2 cache的数据进行替换以腾出空间；在L2容量足够的情况下，一般只会从GM读一次，数据块的重复读取会发生在从L2读取，因此L1容量大小会直接影响重复读的数据量和性能
|
||||
3、从GM读取数据时存在访存效率问题，影响访存效率的主要有几个因素，重要性依次递减，一是参与核数，GM带宽所有核共享并发读取才能尽量充分利用带宽，至少要3/4的核并发才能达到90%以上的带宽利用率，二是单核读取的数据量越大越能达到高带宽利用率，三是单次搬移的数据块越大越能达到高带宽利用率，四是ND2NZ指令的dValue要128Byte最好是256Byte或512Byte(例如在GM以ND排布的非转置左矩阵的K维度、非转置右矩阵的N维度上所搬移的数据量对应单次搬移的dValue)
|
||||
4、BMM算子当前主要是MergeBatch、IterBatch、StreamK、ASW_Basic这几个软件实现分支
|
||||
5、关于tiling和swizzle的描述可以参考当前算子结构体中的描述，MatmulConfig参数说明，L0C的大小影响M、N的切分
|
||||
6、给定具体case，要能给出最优软件实现方案，并能评估端到端算子时延；给定具体case，并给定具体tiling和swizzle方案也要能评估端到端算子时延
|
||||
另外单独补充说明下MergeBatch、IterBatch、StreamK、ASW_Basic这几个软件实现分支，可参考ops-nn/matmul/batch_mat_mul_v3算子源码，我要强调的是源码未必是最优的，要以批判的眼光审视源码，参考并优化方案：
|
||||
1、其中MergeBatch和IterBatch都是先按Batch分核，核内计算时MergeBatch会进行[bM,K]@[K,bN]的计算，然后按[M,N]的Block取Trace，会存在算力浪费，不过一般访存Bound，计算时延可以被掩盖，浪费一点也没关系，IterBatch在核内计算时就是逐个Batch的进行计算
|
||||
2、StreamK是在B、M、N切分无法有效利用核数并行计算时，通过切K达到多核有效计算，提升核负载利用率的目的，但存在核间的Reduce的额外开销
|
||||
3、实践中，大多数case会走ASW_Basic分支，该分支不切K，对于B、M、N都可以切
|
||||
请参考我的补充说明，重新审视并优化《BMM最优软件实现方案设计.md》
|
||||
|
||||
-------------------------
|
||||
|
||||
我想设计BMM算子在NPU(昇腾950PR)上的最优软件实现，算子接口大致与batch_mat_mul_v3类似，目标是任何shape、dtype的BMM case来了，都能得到最优的软件实现方案，所谓最优就是最终可以达成在该芯片上最短的端到端算子时延，你先拿出个设计方案输出到本地，要有理有据，下面有一些tips供参考
|
||||
|
||||
tips1：算子软件实现方案设计主要是结合芯片微架构特征和规格，设计分块到各个AiC核上的搬移、计算的tiling和swizzle(所谓swizzle简单说就是分块执行的顺序，以及哪个分块在哪个核上做)
|
||||
|
||||
tips2：据我了解GM带宽1.6TB/s是读写共享，L2的带宽5.2TB/s是读写各自独享，Cube计算的输出是可以直接写到L2的，所有最终输出都写到L2也算计算完成。
|
||||
|
||||
tips3：关于核间切分的一些想法如下
|
||||
核间切分
|
||||
切B
|
||||
读入
|
||||
每个数据块都有对应的核，且每个数据块只会被固定的1个核读取
|
||||
每核独立读取各自的多个数据块，不会读取其他核的数据块
|
||||
计算
|
||||
每个最终结果数据块由每个核独立计算产生，不依赖其他核的结果
|
||||
在单核内，该核的任意输入数据块可以产生该输入数据块能产生的全部输出数据块
|
||||
写出
|
||||
每个核只写出最终结果，没有中间结果写出
|
||||
切M或N
|
||||
读入
|
||||
若是切M后左矩阵分块被分到不同核，则存在同一右矩阵分块被不同核(重复)读取
|
||||
若是切N后右矩阵分块被分到不同核，则存在同一左矩阵分块被不同核(重复)读取
|
||||
单核会读取多个数据块，单个数据块可能会被一个或多个核读取
|
||||
计算
|
||||
每个最终结果数据块由每个核独立计算产生，不依赖其他核的结果
|
||||
在单核内，该核的某个输入数据块只可以产生该输入数据块能产生的部分输出数据块
|
||||
写出
|
||||
每个核只写出最终结果，没有中间结果写出
|
||||
切K
|
||||
读入
|
||||
每个数据块只会被固定的1个核读取
|
||||
每核独立读取各自的多个数据块，不会读取其他核的数据块
|
||||
计算
|
||||
每个最终结果数据块由多个核计算产生，依赖多个核的结果，且需要Reduce
|
||||
在单核内，该核的任意输入数据块可以产生该输入数据块能产生的全部输出数据块的中间结果
|
||||
写出
|
||||
单核存在中间结果写出，需要与其他核的中间结果一起做reduce才能产生最终输出数据分块
|
||||
|
||||
Reference in New Issue
Block a user