【Hackathon No.36】优化 lerp_grad op 在 GPU 上的计算性能

[Rayman96]

PR types

Performance optimization

PR changes

OPs

Describe

实验开发环境： 硬件：Tesla-P4 软件环境：CUDA 11.2，CuDNN 8

Case No.	input_shape	data_type	Paddle_modify Perf(us)	Perf_over_paddle_origin(%)	Perf_over_pytorch(%)
1	[16, 102400]	float32	134.98	65.56%	41.04% ｜
2	[16, 204800]	float64	543.17	37.96%	42.55%

代码逻辑简介： 对于cpu端，直接复制原本的逻辑，可以正常运行。 对于GPU端，需要考虑X，Y，W三者broadcoat的情况。 1. 真正计算过程中只涉及W和Dout，如果w是单个值（大部分情况），可以不对weight进行broadcast，直接与dout相乘； 2. 如果weight是矩阵，需要先broadcast到dout的维度然后对应相乘。 3. 对于X，Y维度不同时，如果是类似（x: 1x2x3, y:2x2x3）这样只需要broadcast的维度在起始维度，那么可以不用将x拓展到y的维度。 4. 如果是类似（x:2x1x3, y:2x2x3）这样需要拓展的维度在中间的话，就需要先将x拓展进行计算，计算完成后在reduce回自身维度。

4的计算时间与原始计算步骤相当，从1～4的计算过程逐渐增大。所以情况1的性能优化应该最好，4的最差

[paddle-bot[bot]]

你的PR提交成功，感谢你对开源项目的贡献! 请关注后续CI自动化测试结果，详情请参考Paddle-CI手册。 Your PR has been submitted. Thanks for your contribution! Please wait for the result of CI firstly. See Paddle CI Manual for details.

[paddle-bot[bot]]

✅ This PR's description meets the template requirements! Please wait for other CI results.

[Rayman96]

@Ligoml 请问下目前有两个失败的流水线检查，CE-Framework中显示test_quantile.py存在bug，这个好像测试的不是我修改的算子。 CI-Coverage里显示覆盖不足，这里的覆盖是使用的paddle/python/paddle/fluid/tests/unittests/test_lerp_op.py这个单测文件吗？原有的单测里确实覆盖不全，是否需要我修改这个单测文件。

[Rayman96]

注释掉了一个新增的单测

这个单测结果是正确的，print出grad值都是一致的，但是Optest里的check_grad会判定diff大于1e-7, 好像是assertLessEqual判定的错误

[Rayman96]

Build昨天是成功的，现在报错也看不太懂是什么原因。大佬们能帮忙看下吗？以及Op的内容麻烦审核

[Rayman96]

麻烦请教各位大佬，现在CE不通过的错误是什么原因呢？ 另外CI-Coverage失败是说CPU端代码的问题，CPU端我是直接拷贝的原有实现应该也没有问题

[ZzSean]

建议不在.cc文件里增加代码，还是使用impl.h就可以，这样应该不会报覆盖率的问题

[Rayman96]

建议不在.cc文件里增加代码，还是使用impl.h就可以，这样应该不会报覆盖率的问题

好的我试试

[Rayman96]

@ZzSean 请问CI-build里提示refusing to merge unrelated histories是什么原因呢？现在只保留了两条commit

update: 我重跑CI-Clone后不提示上边的错了，但是build又提示docker md5 check failed😂

[CLAassistant]

All committers have signed the CLA.

[luotao1]

请问CI-build里提示refusing to merge unrelated histories是什么原因呢？现在只保留了两条commit

和commit数量无关，需要merge下最新的develop分支

[Rayman96]

请问CI-build里提示refusing to merge unrelated histories是什么原因呢？现在只保留了两条commit

和commit数量无关，需要merge下最新的develop分支

好的谢谢 应该可以了

[AnnaTrainingG]

LGTM for PR-CI-Kunlun-KP-Build

[Xreki]

原OP Benchmark里面的2个lerp配置不够典型，故https://github.com/PaddlePaddle/benchmark/pull/1530 将第2个double类型的配置改成了一个实际模型中用到且性能很差的配置。另外PR中还贴了模型中几个其他的配置的性能，可供参考。

OP Benchmark CI性能如下：

• 配置一：前向+反向总GPU时间加速比为1.77x，反向GPU时间加速比为2.26x。

• 配置一：pr优化后nvprof结果：

• 配置二：前向+反向总GPU时间加速比为686x，反向GPU时间加速比为1597x。

• 配置二：pr优化后nvprof结果：

优化效果汇总如下表，符合黑客松的验收要求：

---

若您还有兴趣做进一步性能优化，可以考虑以下几个方面：

1. 目前没有w.shape不是[1]的配置的性能，L123 - L146 BroadcastTensorsKernel + LerpGradKernelImpl可以考虑使用一个BroadcastKernel调用来替换。
2. nvprof中存在[CUDA memcpy DtoD]，应该是来自反向，可以排查下来源，看是否可以避免。

[Rayman96]

原OP Benchmark里面的2个lerp配置不够典型，故PaddlePaddle/benchmark#1530 将第2个double类型的配置改成了一个实际模型中用到且性能很差的配置。另外PR中还贴了模型中几个其他的配置的性能，可供参考。

OP Benchmark CI性能如下：

• 配置一：前向+反向总GPU时间加速比为1.77x，反向GPU时间加速比为2.26x。
• 配置一：pr优化后nvprof结果：
• 配置二：前向+反向总GPU时间加速比为686x，反向GPU时间加速比为1597x。
• 配置二：pr优化后nvprof结果：

优化效果汇总如下表，符合黑客松的验收要求：

若您还有兴趣做进一步性能优化，可以考虑以下几个方面：

1. 目前没有w.shape不是[1]的配置的性能，L123 - L146 BroadcastTensorsKernel + LerpGradKernelImpl可以考虑使用一个BroadcastKernel调用来替换。
2. nvprof中存在[CUDA memcpy DtoD]，应该是来自反向，可以排查下来源，看是否可以避免。

回复：1. 我在benchmark中增加了多一条配置：x: [16, 1, 1, ,1], y:[16, 3, 244, 244], w:[3, 1, 244]，三者都需要进行broadcast的情况。前向由于是一样的实现没有提升，后向大概提升100x，我后续补一下详细结果（已更新）。

两个kernel替换的工作下一次优化时进行 2. [CUDA memcpy DtoD] 的操作我查看运行图好像是由于benchmark执行中产生。我用benchmark测试别的算子也发现在前向和后向中间会加入一段 memcpy DtoD，具体原因还没有详细研究。

[Xreki]

@Rayman96 这个DtoD拷贝不是benchmark产生的，你看https://github.com/PaddlePaddle/benchmark/pull/1530 ，我跑的develop的nvprof，并没有这个DtoD拷贝。

[Rayman96]

PaddlePaddle/benchmark#1530

确实比较奇怪，会不会是由于https://github.com/PaddlePaddle/benchmark/pull/1530 里全都是Eigen实现所以没有呀？ 我在本地测试好像只要有自己实现的kernel就会出现DtoD