Support Div and FloorDiv functor in elementwise system

[JamesLim-sy]

PR types

Performance optimization

PR changes

OPs

Describe

1. Basing on new elementwise + broadcast system support binary functors below :
   Div
   Floor_div

2. The performance variation is below:
   

The explicit comparison of floor_div is below:

x.shape	y.shape	data type	Paddle dev /us	Paddle Opti /us	Pytorch /us	Perf diff (with respect to pytorch)
[16, 128, 8]	[16, 128, 8]	int64	2.0700	1.814	2.006	slow 3.19% -> fast 9.57%
[300, 128, 100]	[300, 128, 100]	int32	57.514	56.785	56.587	slow 1.64% -> slow 0.35%
[[300, 128, 100]	[1]	int64	78.224	76.359	76.550	slow 2.19 -> fast 0.25%

3. As can be seen in the table, the time cost of most of test cases reflect the great improvment in logical ops after optimization of Elementwise and Broadcast op.

[paddle-bot-old]

Thanks for your contribution!
Please wait for the result of CI firstly. See Paddle CI Manual for details.

[paddle-bot-old]

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

[Xreki]

不用调trunc函数了吗？那和div计算就没区别了啊

[JamesLim-sy]

Floor_div 处理的数据类型仅有 int32和 int64，返回值如果也是 int32 或 int64的话，会有自动截断操作。本地也搭建了测试脚本发现两者的计算结果相同。

import numpy  as np
import paddle as pd

npx = np.array([9, -11, -8, 7])
npy = np.array([2,   3,  3, 2])
x = pd.to_tensor(npx, dtype='int32')
y = pd.to_tensor(npy, dtype='int32')

z2 = pd.divide(x, y)
z1 = pd.floor_divide(x, y)
result = pd.subtract(z1, z2)  # result = [0, 0, 0, 0]

目前对比的结果显示，针对 floor_div 的计算，Paddle和Pytorch的计算结果是一样的，具体表现是在针对 floor_div(-8, 3) 这种计算时，
paddle和 pytorch计算的规则生成的结果是 -2，向中心点floor；
Numpy 和 tensorflow的结果是 -3，向x负半轴方向floor。

• 感觉可以再讨论一下是否需要修改Paddle中floor_div的计算规则。

[Xreki]

找op负责人确认下，或者当前pr先保留trunc。

[Xreki]

L41和L43写的一样？另外这2行分别加个注释说明下。

[JamesLim-sy]

L43出现笔误，下个commit修改掉。

[Xreki]

为什么要用模板呢？

[JamesLim-sy]

这里用的是偷懒的做法，增加模板或者函数头增加static 关键字，防止了编译过程出现函数重定义的问题。实际修改方法应该是将新开一个.cu文件，然后把函数放进.cu里面完成实例化。

[Xreki]

不应该啊，文件开头不是有#pragma once？

[JamesLim-sy]

查了一下stackoverflow 这个问题不能通过 #pragma once 解决。总结出来的问题有以下两种：
（1）仍旧另起一个.cu文件实例化函数体；
（2）加inline 或者 static 关键字；
偷了个懒，选择加了个inline 关键字解决。

[Xreki]

这里，float16的向量化长度可能返回8，但是你没有检查地址是否满足vec8对齐的要求。

[JamesLim-sy]

这点确实考虑漏掉了，按照建议修改，下个Commit提交。

[Xreki]

我们的AlignedVector或许可以改成继承Array类，定义AlignedArray。

Paddle/paddle/fluid/framework/array.h

Lines 24 to 35 in 42c1297

	template <typename T, size_t N>
	class Array {
	public:
	static constexpr size_t kSize = N;
	HOSTDEVICE inline Array() {}
	template <typename... Args>
	HOSTDEVICE inline explicit Array(const T &val, Args... args) {
	static_assert(N == sizeof...(Args) + 1, "Invalid argument");
	UnrollVarArgsAssign<T>::Run(data_, val, args...);
	}

[Xreki]

LGTM

[chenwhql]

lgtm for paddle enforce