【Hackathon 7th No.28】为 paddle.clip 进行功能增强

[idontkonwher]

PR Category

Operator Mechanism

PR Types

Improvements

Description

1. 参考Torch 和 Numpy 的 API，实现了clip 输入、Min 和 Max 之间的广播机制（当然包括普通的Elementwise）
2. 去除了强制要求Max > Min 的要求 （与Torch 和 Numpy 一致，严格按照 minimum(a_max, maximum(a, a_min)) 的公式顺序执行。
3. 已知问题：Torch 支持类型提升，本PR的Paddle的实现中强制要求Min Max 类型和input一致，这部分需要讨论。
4. 已知问题：MKLDNN实现和XPU实现不支持相关功能，并未进行修改。
5. 已知问题：实现的相对较粗糙，性能未进行测试，经验有限还麻烦多指正。

[paddle-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.

[zhwesky2010]

@idontkonwher

1. 目前会对性能造成较大影响，因为to_tensor是一个cpu到gpu拷贝的过程，有两种方式可能性能会好一些：

• 【对当前性能可能有影响】如果min/max为float，则统一成min_tensor=full([], min, x.dtype)，创建一个0-D Tensor替代原来的min/max
• 【对当前性能必然无影响】在原来的kernel后面加一个可选的min_tensor、max_tensor，或者加一个新的kernel为clip_tensor，支持min/max为Tensor，也就是float和Tensor不共用一个传入的参数

2. 对于Tensor情况需要支持类型提升，可以提前cast为x.dtype，对于float情况应该就无所谓类型提升了
3. MKLDNN和XPU理论上也是需要支持该功能的，未支持原因是底层SDK不支持吗？

[idontkonwher]

@idontkonwher

1. 目前会对性能造成较大影响，因为to_tensor是一个cpu到gpu拷贝的过程，有两种方式可能性能会好一些：

• 【对当前性能可能有影响】如果min/max为float，则统一成min_tensor=full([], min, x.dtype)，创建一个0-D Tensor替代原来的min/max
• 【对当前性能必然无影响】在原来的kernel后面加一个可选的min_tensor、max_tensor，或者加一个新的kernel为clip_tensor，支持min/max为Tensor，也就是float和Tensor不共用一个传入的参数

2. 对于Tensor情况需要支持类型提升，可以提前cast为x.dtype，对于float情况应该就无所谓类型提升了
3. MKLDNN和XPU理论上也是需要支持该功能的，未支持原因是底层SDK不支持吗？

多谢回复！
对于第一个问题，没有考虑到这部分的开销。修改成第二个可能会好一些，使用full的话也会额外launch一个kernel，我会尝试重新注册一个算子并绑定到tensor输入的情况下，不过要是一个scaler一个tensor怎么办啊。直接报非法输入可以吗？如果要兼容这种输入的话就只能选第一种了吧。
第二个问题，举个例子如果torch输入为x:fp32 min:fp64, max:fp64, 那么返回值是fp64，但是在paddle下因为kernel只能拿到一个类型相关的模板类型参数T，不太清楚应该怎么做这个类型提升，还是说我需要直接在python端拿到输入后就按照精度/表示范围最大的那个cast 一下。
第三个问题的话，这两个的API我都不是很熟悉，mkldnn / onednn的api看文档应该是不支持广播操作的。xpu的文档不知道可不可以找到，不过我后续还会继续尝试一下，如果大佬有相关信息的话也麻烦告诉一下。
另：CI出现了很多报错，我会尽快尝试解决的（最近有其他事效率有点低...
@zhwesky2010

[paddle-ci-bot]

Sorry to inform you that eb1cc1f's CIs have passed for more than 7 days. To prevent PR conflicts, you need to re-run all CIs manually.

[zhwesky2010]

@idontkonwher

1. 目前会对性能造成较大影响，因为to_tensor是一个cpu到gpu拷贝的过程，有两种方式可能性能会好一些：

• 【对当前性能可能有影响】如果min/max为float，则统一成min_tensor=full([], min, x.dtype)，创建一个0-D Tensor替代原来的min/max
• 【对当前性能必然无影响】在原来的kernel后面加一个可选的min_tensor、max_tensor，或者加一个新的kernel为clip_tensor，支持min/max为Tensor，也就是float和Tensor不共用一个传入的参数

2. 对于Tensor情况需要支持类型提升，可以提前cast为x.dtype，对于float情况应该就无所谓类型提升了
3. MKLDNN和XPU理论上也是需要支持该功能的，未支持原因是底层SDK不支持吗？

多谢回复！ 对于第一个问题，没有考虑到这部分的开销。修改成第二个可能会好一些，使用full的话也会额外launch一个kernel，我会尝试重新注册一个算子并绑定到tensor输入的情况下，不过要是一个scaler一个tensor怎么办啊。直接报非法输入可以吗？如果要兼容这种输入的话就只能选第一种了吧。 第二个问题，举个例子如果torch输入为x:fp32 min:fp64, max:fp64, 那么返回值是fp64，但是在paddle下因为kernel只能拿到一个类型相关的模板类型参数T，不太清楚应该怎么做这个类型提升，还是说我需要直接在python端拿到输入后就按照精度/表示范围最大的那个cast 一下。 第三个问题的话，这两个的API我都不是很熟悉，mkldnn / onednn的api看文档应该是不支持广播操作的。xpu的文档不知道可不可以找到，不过我后续还会继续尝试一下，如果大佬有相关信息的话也麻烦告诉一下。 另：CI出现了很多报错，我会尽快尝试解决的（最近有其他事效率有点低... @zhwesky2010

1. 这种不用考虑太复杂，torch没有这种用法 就不用管了，直接报错就行
2. python层cast就行吧
3. 这个自己查询一下吧，看有没有可参考的类似API