您好，非常感谢您的反馈，当前已联系相应专家

您好，非常感谢您的反馈，当前已联系相应专家

@vallenChen

感谢！

当前SOC资源是多核竞争的，多核同时读写不保证每个核的带宽。实际上，甜点不是“想”出来的，是“摸”出来的。对于IO占主导的算子，建议尽可能的从512B对齐的维度去设计搬运粒度，UB上最小访问粒度：32B。

当前SOC资源是多核竞争的，多核同时读写不保证每个核的带宽。实际上，甜点不是“想”出来的，是“摸”出来的。对于IO占主导的算子，建议尽可能的从512B对齐的维度去设计搬运粒度，从经验上建议尝试>32KB/burst的颗粒度。

@vallenChen 感谢大佬分享经验。

$>32KB/burst$是一个很有挑战的事情，以UB大小限制位192KB来计算，2个输入、1个输出、1个片上的temp，开启double buffer后共有（2+1）*2+1 = 7份数据，那么192/7/32=876 个 数据的slot，与512对齐后，876/16*16=864个。因此输入数据最多为864*32B=27KB数据。很难实现到32KB/burst的颗粒度。
这种情况下，算法设计上已经是比较绝望了，有无改进方法。另外，现在发现一个奇怪的问题：
当有mte2开启多个数据通路后，不同数据通路之间有明显的竞争状态，会导致每个数据通路的带宽都降低（output搬出一个tile时间是340us，但是MTE2搬入x1需要500多us，x2甚至需要700-900us），这是硬件特性环是算法问题，有解决方法吗？

除开算法优化部分，考虑硬件：这是910B4的性能问题吗？我换910B2是否有明显改善（除了MTE2带宽扩到了1.6T外）。

当前SOC资源是多核竞争的，多核同时读写不保证每个核的带宽。实际上，甜点不是“想”出来的，是“摸”出来的。对于IO占主导的算子，建议尽可能的从512B对齐的维度去设计搬运粒度，从经验上建议尝试>32KB/burst的颗粒度。

@vallenChen 感谢大佬分享经验。

$>32KB/burst$是一个很有挑战的事情，以UB大小限制位192KB来计算，2个输入、1个输出、1个片上的temp，开启double buffer后共有（2+1）*2+1 = 7份数据，那么192/7/32=876 个 数据的slot，与512对齐后，876/16*16=864个。因此输入数据最多为864*32B=27KB数据。很难实现到32KB/burst的颗粒度。
这种情况下，算法设计上已经是比较绝望了，有无改进方法。另外，现在发现一个奇怪的问题：
当有mte2开启多个数据通路后，不同数据通路之间有明显的竞争状态，会导致每个数据通路的带宽都降低（output搬出一个tile时间是340us，但是MTE2搬入x1需要500多us，x2甚至需要700-900us），这是硬件特性环是算法问题，有解决方法吗？

除开算法优化部分，考虑硬件：这是910B4的性能问题吗？我换910B2是否有明显改善（除了MTE2带宽扩到了1.6T外）。

@KervinSherman
您好开发者，非常感谢您对当前带宽的探索。

• 对于上文中开启double buffer后最多为27KB/burst的情况，尽可能多的使用即可，从经验上来说小于32KB/burst时，带宽是随数据粒度递增的。对于double buffer的使用有一些建议：
  • 当数据搬运时间较短，而Vector计算时间显著较长时，由于数据搬运在整个计算过程中的时间占比较低，double buffer机制带来的性能收益会偏小。
  • 当原始数据较小且Vector可一次性完成所有数据量的计算时，强行使用double buffer会降低Vector计算资源的利用率，最终效果可能适得其反。
• 就mte2开启多数据通路后数据带宽下降是一个资源问题，可以这么理解：MTE通路可以搬运货物A或者B，搬运货物A多点那么搬运货物B就少点，反之亦然。相较于只搬运货物A或者货物B（单独数据搬运）带宽下降，是因为同时搬运了货物A和B。多通路下对比单通路确实会降低带宽。
• 和上面说的一样，甜点是摸出来的，可以尝试固定搬运的总数据量，尝试不同的nBurst和lenBurst组合来选择当前场景下带宽利用率最高的tile大小。
• 910B2和910B4对于多通路中的竞争带宽应该是没有区别的属于硬件特性。

感谢大佬解答，万分宝贵的经验。