已开启
[Requirement|需求建议]: cumsum性能优化 #5
StoneChan_创建于  14 天前
StoneChan_
StoneChan_成员
14 天前 创建

Thanks for sending an requirement! Please fill in the following template to help quickly solve your problem.

一、背景信息 (必填)

cumsum性能优化

二、价值/作用 (必填)

三、设计方案 (必填)

需求建议
一、 simd: 忠星的建议:fp32/int32
1、 第一次核内: 搬出,不要scatter,就按照转后的搬出
nddma+ add / gather+ add: 不改算法,只修改搬入
2、 第二次核间:直接按照前面搬出的,搬入,省了gather
mov_align +add: 搬入
scatter:散列
mov_align: 搬出
--》数学家分析优化: 变成顺序累加: coreN_前缀和=core0+core1+,,,coreN-1, 直接和内部的vector做累加,不需要使用cumsum
3、竞品分析
3.1 【单R轴】场景
Decoupled look back 算法
认为每个Block(NPU上是一个核)处理一个tile块,其中每个block内部有自己的scan算法(常见的如顺序cumsum,Sklansky等等),Block之间有另外的算法去循环
核内:待继续调研
核间:非Sklansky

3.2 【1 < 尾轴A < 8】场景
sklansky
需要迭代开发前测试一下,看看和竞品的性能比较结果,最后判断是否要将新方案的模版扩展为非单R轴 场景

4、新方案
以下两种方案的性能目标为torch gpu竞品的0.5

4.1、SIMD优化方案简述
UB内:(fp类型做sklansky,int类型做顺序累加)
(1)nddma转置搬运成将单R轴的数据转换为紧凑排布的数据(如下图右部),再做加法,保持紧凑排布的数据直接搬出GM
(2)dataMove直接原序列搬运到UB,再VF中使用gather指令紧凑排布的数据,再做加法,保持紧凑排布的数据直接搬出GM
备注:以上两个方案需要时间验证测试完后决策使用;使用gather指令时,需要注意避免bank冲突,gather指令的理论性能应该可以达到128B/cycle。

核间:非sklansky,顺序累加
直接使用dataMove搬入紧凑排布的数据,获取前coreN的累加和,直接合本次的搬入数据做vector做累加(如下图)
加法完毕后,使用scatter还原数据,最后dataMove搬出到GM上

3.1 使能方式(涉及哪些框架:如Aclnn直调、Pytorch训练等)
3.2 总体设计
3.2.1 算子支持的数据类型
3.2.2 host侧设计
3.2.3 kernel侧设计
3.3 支持硬件

3.4 算子约束限制

💡 备注(选填)

likedislike
StoneChan_StoneChan_成员
13 天前 修改了issue 的描述