CANN AICPU算子耗时分析及优化探索

最新推荐文章于 2024-05-19 11:00:00 发布

hshyds

最新推荐文章于 2024-05-19 11:00:00 发布

阅读量291

点赞数

文章标签： tensorflow 深度学习

本文链接：https://blog.csdn.net/hshyds/article/details/120400209

版权

本文通过对比分析CANN与TensorFlow的GreaterEqual算子性能，揭示了CANN在数据量增大时性能下降的问题，特别是在uint8和int8数据类型上的显著劣化。通过引入向量化优化，性能得到了显著提升，但面临向量化局限性和广播操作的挑战。建议优化并行阈值，启用编译器自动向量化，升级Eigen库以支持原生fp16计算，并改进Bcast实现以提升性能。

摘要由CSDN通过智能技术生成

1. 分析目的

在实际开发CANN算子的过程中，常常出现算子功能正常，但性能远低于TensorFlow对标算子的情况。针对这个问题，本文以GreaterEqual作为测试算子，该算子计算逻辑较为简单(output = input1 >= input2)，旨在尽可能降低计算耗时，使得算子耗时尽可能以数据操作和算子调度作为主体。

2. 测试代码与平台介绍

本次测试平台为OpenLab提供的Ascend服务器，搭载Ascend910A，CANN Toolkit版本号为5.0.2alpha005。

自研测试代码参考cac625f243dfe7b04dbb2a82059cd0e4349f77d1这一commit进行修改，该commit针对广播操作性能进行了优化。自研设置并行阈值：含广播操作计算为8K，不含广播操作计算为32K。

GreaterEqual的TensorFlow对标算子为TensorFlow1.15版本算子，canndev对标算子commit为d660e086717b94b8cfb3f35a8e08046ca0461772，该版本算子尝试利用Eigen库的broadcast操作规避canndev源码仓Bcast性能不足的问题，但未启用并行计算进行加速。

测试数据我设置了涉及广播操作和不涉及广播操作的两批数据，涉及广播操作的测试数据又分为需广播Tensor的元素个数为1和元素个数不为1两种，测试了int8、int16、int32、int64、uint8、float16、float32、float64共8种TensorFlow对标算子支持的数据类型，每种数据类型分别设置了128B、256B、1K、2K、4K、8K、16K、32K、64K、128K、256K、1M、2M、8M共14个数据规模梯度，详细数据规模与shape对应关系如下：

3. 单线程性能分析

这一部分旨在测试单线程处理数据CANN算子与TensorFlow算子性能差距。为避免广播操作对测试结果产生影响，本次测试数据采用不涉及广播操作的数据批次。

图1 单线程耗时比例

可以看出，对于数据量低于2K的小型数据规模，CANN算子相比于TensorFlow有一定性能优势，但随着数据量的增加，CANN算子性能出现显著性能劣化，尤其是uint8这一数据类型，劣化程度十分严重，性能劣化高达6.57倍。对于非C++标准的float16这一数据类型，二者均采用Eigen库中的half数据类型进行代替，测试结果性能较为接近。

图2 计算1K数据耗时

我还测试了CANN和TF单核计算16K-8M数据量时，计算1K数据所消耗的时间。

可以看出，TensorFlow随着数据类型占用空间的增大，耗时也成比例的相应增加。而奇怪的是，CANN的int8、uint8耗时与int16相近，这一特点同样体现在耗时比例int8和uint8的性能劣化程度远高于其他数据类型，猜测有可能是因为int8和uint8是扩展至16位再进行计算。CANN在float32和float64这两个数据类型的表现也十分奇怪，随着数据量的增加，耗时发生了较大波动。具体情况在向量化代码与性能分析部分尝试进行了分析优化。