Merge branch 'develop' of https://github.com/PaddlePaddle/Paddle into cross_channel_norm
sweetsky0901
7 years ago
commit
333995a700
File diff suppressed because it is too large
Load Diff
@ -0,0 +1,91 @@
|
|||||||
|
# Design Doc: The Keys of Operator Kernel Type
|
||||||
|
## Problem
|
||||||
|
An operator can have different kernel implementations, and each operator will have a map to store the related kernels. Fluid uses `OpKernelType` as a key to identify a unique Kernel. Before an operator runs, an certain kernel must be chosen by a key of `OpKernelType`. Currently, `OpKernelType` is defined as follows:
|
||||||
|
|
||||||
|
```cpp
|
||||||
|
struct OpKernelType {
|
||||||
|
platform::Place place_;
|
||||||
|
proto::DataType data_type_;
|
||||||
|
};
|
||||||
|
```
|
||||||
|
For more details, please refer to [codes](https://github.com/PaddlePaddle/Paddle/blob/2d5ec16bc8a09fb8e0f62c89b116b0cd1d333907/paddle/framework/operator.h#L348-L374) in github.
|
||||||
|
|
||||||
|
It contains two keys, `Place` and `DataType`. And these two keys will be hashed to a unique key to represent a certain type of kernel. However, these two keys are not enough. We need a more complete representation of `OpKernelType`.
|
||||||
|
|
||||||
|
We often implement a kernel of an operator with some computing library in certain device(place). Please remind that computing library and device are not one-to-one corresponding. A device can have a lot of computing libraries and a computing library can also support several devices.
|
||||||
|
|
||||||
|
For example, Eigen library can support Nvidia GPU/AMD GPU/CPU. And MKLDNN library can support Intel CPU/Intel FPGA. Both `Place` and `Library` should be a key of `OpKernelType`.
|
||||||
|
|
||||||
|
It's obvious that different DataTypes, like fp64/fp32/int8 will have different kernels. But the data layout of a Tensor will also lead to different implementation. Please refer to the batch norm operator [kernels](https://github.com/PaddlePaddle/Paddle/blob/a948fac4d0ad7e0412d373b8aabeb711c2899563/paddle/operators/batch_norm_op.cc#L180-L209). Data Layout should also be taken into consideration.
|
||||||
|
|
||||||
|
## Solution
|
||||||
|
|
||||||
|
There are four keys to determine a kernel type of an operator: `Place`/`Library`/`DataType`/`Layout`.
|
||||||
|
|
||||||
|
```cpp
|
||||||
|
struct OpKernelType {
|
||||||
|
platform::Place place_;
|
||||||
|
platform::Library library_;
|
||||||
|
proto::DataType data_type_;
|
||||||
|
framework::Layout layout_;
|
||||||
|
};
|
||||||
|
```
|
||||||
|
|
||||||
|
Following is the details:
|
||||||
|
|
||||||
|
### Place
|
||||||
|
|
||||||
|
`Place` is defined as follows:
|
||||||
|
|
||||||
|
```cpp
|
||||||
|
typedef boost::variant<CUDAPlace, ROCmPlace, FPGAPlace, CPUPlace> Place;
|
||||||
|
```
|
||||||
|
|
||||||
|
`Place` is to represent the device memory where data is locating.
|
||||||
|
|
||||||
|
|
||||||
|
### Library
|
||||||
|
|
||||||
|
One operator kernel is usually implemented based on one library. `Library` is defined as a enum variable:
|
||||||
|
|
||||||
|
```cpp
|
||||||
|
enum Library { Plain, MKLDNN, CUDNN };
|
||||||
|
```
|
||||||
|
|
||||||
|
We use `Plain` enumerator to represent default library. Since most operators in Fluid are implemented based on `Eigen` library, we take `Eigen` library as the `Plain` enumerator.
|
||||||
|
A library usually has a corresponding `DeviceContext` which contains some handles needed by computation. Fluid now have two default DeviceContexts in CPU and CUDA, `CPUDeviceContext` and `CUDADeviceContext`. `CPUDeviceContext` contains a Eigen library handle and `CDUADeviceContext` contains a Eigen library handle and cuBLAS handle.
|
||||||
|
|
||||||
|
If we want to support new Library, a new enumerator need to be added to `Library` and a new corresponding `LibraryDeviceContext` will be created.
|
||||||
|
|
||||||
|
|
||||||
|
### DataType
|
||||||
|
|
||||||
|
|
||||||
|
`DataType` is defined in [framework.proto](https://github.com/PaddlePaddle/Paddle/blob/develop/paddle/framework/framework.proto). Currently, int32/int64/fp32/fp64 are supported.
|
||||||
|
|
||||||
|
### Layout
|
||||||
|
|
||||||
|
Actually, a Tensor is a view of a block of memory. Besides a pointer to the memory, we also have to get some other descriptions of this block of memory, such as shape(ddim), stride, and layout.
|
||||||
|
|
||||||
|
Different layout leads to different implementation of operator kernel. There are mainly 4 principles we have to follow to support layout in our fluid framework.
|
||||||
|
|
||||||
|
- We take layout as a data member of Tensor. Layout is actually a enum variable. If fluid is built with MKLDNN, then, the memory format in MKLDNN will be added into this enum variable too.
|
||||||
|
|
||||||
|
- Users have to set layout for input data. And some operators like fill_constant/random, also have to set layout of generating data. Of course, we can have some default layout, like NCHW.
|
||||||
|
|
||||||
|
- The inference of Layout is at run-time, not compile-time.
|
||||||
|
|
||||||
|
- Every operator have to implement different kernels for different layouts. Let's take MKLDNN as an example, if we want to implement a MKLDNN convolution operator, we have to realize all the kernels for different layout, list at [here](http://01org.github.io/mkl-dnn/structmkldnn_1_1memory.html). And we will have a special macro to do registering kernels for MKLDNN operators.
|
||||||
|
|
||||||
|
`Layout` is also defined as a enum variable:
|
||||||
|
|
||||||
|
```cpp
|
||||||
|
enum Layout {
|
||||||
|
kNCHW,
|
||||||
|
kNHWC,
|
||||||
|
#ifdef PADDLE_WITH_MKLDNN
|
||||||
|
knChw8c
|
||||||
|
...
|
||||||
|
#endif
|
||||||
|
};
|
||||||
|
```
|
||||||
@ -0,0 +1,43 @@
|
|||||||
|
# Design Doc: Execute the Program with Multi CPU
|
||||||
|
|
||||||
|
## Abstract
|
||||||
|
|
||||||
|
This Design Doc propose an approach to make the user-defined Op graph
|
||||||
|
running with multi-CPU, we will use an auto transpiler to convert the user-defined
|
||||||
|
Op graph to a multi-CPU Op graph, and run `ParallelDo` Op to run the graph.
|
||||||
|
|
||||||
|
## Transpiler
|
||||||
|
|
||||||
|
<img src="src/multi-threads/single-thread@3x.png" width="300">
|
||||||
|
|
||||||
|
After converted:
|
||||||
|
|
||||||
|
<img src="src/multi-threads/multi-threads@3x.png" width="1000">
|
||||||
|
|
||||||
|
## Implement
|
||||||
|
|
||||||
|
- `Multi-CPU Transpiler` will convert the graph to a multi-CPU graph
|
||||||
|
which would be executed with multi-threads.
|
||||||
|
- `BlockingCounter` will `Init/Decrement` an atomic counter, and Blocking `Wait`
|
||||||
|
for the atomic counter become `0`:
|
||||||
|
```cpp
|
||||||
|
BlockingCounter bc(thread_count);
|
||||||
|
for (int i = 0; i < thread_count; ++i) {
|
||||||
|
thread_pool->Start([&bc] {bc.DecrementCount(); })
|
||||||
|
}
|
||||||
|
bc.Wait();
|
||||||
|
```
|
||||||
|
- `ParallelDo` Operator
|
||||||
|
- Initialize a thread pool which is a Singleton.
|
||||||
|
- Use a block id as the input, and create run the specify Block on independent scope
|
||||||
|
with multi-threads.
|
||||||
|
- Initialize a `BlockingCounter` instance and wait until all threads are done.
|
||||||
|
- `Split` Operator will split the Input Tensor into a TensorArray.
|
||||||
|
- `Merge` merge all the gradients which calculated in different threads
|
||||||
|
with `mean/sum/max/min...` method, and then run the Optimizer Op to optimize `W`.
|
||||||
|
|
||||||
|
## TODO
|
||||||
|
|
||||||
|
- Improve the optimizer stage with multi-threads, since we could
|
||||||
|
assign the parameters to the different threads and execute
|
||||||
|
optimizer with multi-threads.
|
||||||
Binary file not shown.
|
After Width: | Height: | Size: 350 KiB |
|
After Width: | Height: | Size: 76 KiB |
@ -0,0 +1,66 @@
|
|||||||
|
## Background
|
||||||
|
Every operator has many kernels because there are multiple data types, places, data layout that Fluid supports. We use the `KernelType` to describe kernel types that operators can hold.
|
||||||
|
|
||||||
|
The `KernelType` is as follows.
|
||||||
|
|
||||||
|
```
|
||||||
|
struct KernelType {
|
||||||
|
Place place_;
|
||||||
|
DataType data_type_;
|
||||||
|
LayoutType layout_;
|
||||||
|
};
|
||||||
|
```
|
||||||
|
|
||||||
|
The `place_` is a descriptor of the device and the computational library, e.g., `MKLDNNPlace`, `CUDAPlace`.
|
||||||
|
|
||||||
|
The `data_type_` is the data type that this kernel performs on, e.g., `FP32`, `INT64`. Note that one kernel may have inputs with different data types. However, it will be a major `data_type`. For example, the `cross_entropy` takes `int64` as it label, and `double`/`float` as its input logit and output cost. The major `data_type` of `cross_entropy` is `float`/`double`.
|
||||||
|
|
||||||
|
The `layout` is useful for some computational library. One example is that MKLDNN uses many kinds of layout, such as `nChw8c`. Each kind of layout will invoke the different kernel.
|
||||||
|
|
||||||
|
## Problem
|
||||||
|
|
||||||
|
We register a kernel for every operator and every kernel type ideally. However, it is impracticable for the following situations.
|
||||||
|
|
||||||
|
1. Some operators, like CRF, are complicated and inefficient to be implemented on GPU. The CRF operator will only have a CPU kernel.
|
||||||
|
2. Some operators will take too many memory. It is better to force them into CPU. However, the rest of operators in this neural network will be performed on GPU, i.e., model parallel problem.
|
||||||
|
3. Some layout and place are particular. One example is that MKLDNN uses `nChw8` and there is no other library uses `nChw8c`.
|
||||||
|
|
||||||
|
Problems under these situations are similar. We can formalise this problem as follow.
|
||||||
|
|
||||||
|
We register kernels with types $KT = \{kt_1, kt_2, kt_3, ...\}$ for one operator. The inputs of this operator should be run on kernel type $kt_{?}$, which the $kt_{?} \notin KT$. How to cast the input of this operator from $kt_{?}$ to any of kernel type in $KT$.
|
||||||
|
|
||||||
|
## Solution
|
||||||
|
|
||||||
|
It is clearly that transforming inputs of an operator toadapt another kernel type is not related to the particular operator. So we should register these transformation methods as global methods.
|
||||||
|
|
||||||
|
We can infer a kernel type from the inputs of an operators. We let this kernel type as `actual kernel type`, which means this kernel type is the actually kernel type that operator should be performed.
|
||||||
|
|
||||||
|
We can get a kernel type by 1) The configuration of operator description. (Users may want to force use `MKL` for `conv` operator). 2) The place of the current executor. (Executor is running on GPU). This kernel type is what we expect the operator will be performed on. We let this kernel type as `expect kernel type`.
|
||||||
|
|
||||||
|
We transform the input data from `actual` to `expect` if the expect kernel type is not as same as actual kernel type.
|
||||||
|
|
||||||
|
The algorithm is described as follow
|
||||||
|
|
||||||
|
```cpp
|
||||||
|
using DataTransformationFN = std::function<void(const Tensor& in, Tensor* out)>;
|
||||||
|
using KernelTypePair = std::pair<KernelType, KernelType>;
|
||||||
|
|
||||||
|
map<KernelTypePair, DataTransformationFN> g_data_transformation_;
|
||||||
|
|
||||||
|
void OpWithKernel::Run() {
|
||||||
|
vec<Tensor> inputs = ...
|
||||||
|
auto actual_kernel_type = GetActualKernelType(inputs);
|
||||||
|
|
||||||
|
// The expected kernel type is related to actual kernel type.
|
||||||
|
// For the most operators, the expected kernel type is as same as
|
||||||
|
// actual kernel type.
|
||||||
|
//
|
||||||
|
// So we pass `actual_kernel_type` as a parameter of
|
||||||
|
// GetExpectedKernelType
|
||||||
|
auto expect_kernel_type = GetExpectedKernelType(actual_kernel_type);
|
||||||
|
|
||||||
|
auto trans = g_data_transformation_[{actual_kernel_type, expect_kernel_type}];
|
||||||
|
|
||||||
|
kernel.run(trans(inputs));
|
||||||
|
}
|
||||||
|
```
|
||||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in new issue