Merge branch 'develop' of https://github.com/PaddlePaddle/Paddle into fix-6590
yangyaming
7 years ago
commit
087fbb498b
Binary file not shown.
|
After Width: | Height: | Size: 121 KiB |
@ -0,0 +1,122 @@
|
||||
# Design Doc: PaddlePaddle Fluid
|
||||
|
||||
## Why Fluid
|
||||
|
||||
When Baidu developed PaddlePaddle in 2013, the only well-known open source deep learning system at the time was Caffe. However, when PaddlePaddle was open-sourced in 2016, many other choices were available. There was a challenge -- what is the need for open sourcing yet another deep learning framework?
|
||||
|
||||
Fluid is the answer. Fluid is similar to PyTorch and TensorFlow Eager Execution, which describes the "process" of training or inference using the concept of a model. In fact in PyTorch, TensorFlow Eager Execution and Fluid, there is no concept of a model at all. The details are covered in the sections below. Fluid is currently more extreme in the above mentioned idea than PyTorch and Eager Execution, and we are trying to push Fluid towards the directions of a compiler and a new programming language for deep learning.
|
||||
|
||||
## The Evolution of Deep Learning Systems
|
||||
|
||||
Deep learning infrastructure is one of the fastest evolving technologies. Within four years, there have already been three generations of technologies invented.
|
||||
|
||||
| Existed since | model as sequence of layers | model as graph of operators | No model |
|
||||
|--|--|--|--|
|
||||
| 2013 | Caffe, Theano, Torch, PaddlePaddle | | |
|
||||
| 2015 | | TensorFlow, MxNet, Caffe2, ONNX, n-graph | |
|
||||
| 2016 | | | PyTorch, TensorFlow Eager Execution, PaddlePaddle Fluid |
|
||||
|
||||
From the above table, we see that the deep learning technology is evolving towards getting rid of the concept of a model. To understand the reasons behind this direction, a comparison of the *programming paradigms* or the ways to program deep learning applications using these systems, would be helpful. The following section goes over these.
|
||||
|
||||
## Deep Learning Programming Paradigms
|
||||
|
||||
With the systems listed as the first or second generation, e.g., Caffe or TensorFlow, an AI application training program looks like the following:
|
||||
|
||||
```python
|
||||
x = layer.data("image")
|
||||
l = layer.data("label")
|
||||
f = layer.fc(x, W)
|
||||
s = layer.softmax(f)
|
||||
c = layer.mse(l, s)
|
||||
|
||||
for i in xrange(1000): # train for 1000 iterations
|
||||
m = read_minibatch()
|
||||
forward({input=x, data=m}, minimize=c)
|
||||
backward(...)
|
||||
|
||||
print W # print the trained model parameters.
|
||||
```
|
||||
|
||||
The above program includes two parts:
|
||||
|
||||
1. The first part describes the model, and
|
||||
2. The second part describes the training process (or inference process) for the model.
|
||||
|
||||
This paradigm has a well-known problem that limits the productivity of programmers. If the programmer made a mistake in configuring the model, the error messages wouldn't show up until the second part is executed and `forward` and `backward` propagations are performed. This makes it difficult for the programmer to debug and locate a mistake that is located blocks away from the actual error prompt.
|
||||
|
||||
This problem of being hard to debug and re-iterate fast on a program is the primary reason that programmers, in general, prefer PyTorch over the older systems. Using PyTorch, we would write the above program as following:
|
||||
|
||||
```python
|
||||
W = tensor(...)
|
||||
|
||||
for i in xrange(1000): # train for 1000 iterations
|
||||
m = read_minibatch()
|
||||
x = m["image"]
|
||||
l = m["label"]
|
||||
f = layer.fc(x, W)
|
||||
s = layer.softmax(f)
|
||||
c = layer.mse(l, s)
|
||||
backward()
|
||||
|
||||
print W # print the trained model parameters.
|
||||
```
|
||||
|
||||
We can see that the main difference is the moving the model configuration part (the first step) into the training loop. This change would allow the mistakes in model configuration to be reported where they actually appear in the programming block. This change also represents the model better, or its forward pass, by keeping the configuration process in the training loop.
|
||||
|
||||
## Describe Arbitrary Models for the Future
|
||||
|
||||
Describing the process instead of the model also brings Fluid, the flexibility to define different non-standard models that haven't been invented yet.
|
||||
|
||||
As we write out the program for the process, we can write an RNN as a loop, instead of an RNN as a layer or as an operator. A PyTorch example would look like the following:
|
||||
|
||||
```python
|
||||
for i in xrange(1000):
|
||||
m = read_minibatch()
|
||||
x = m["sentence"]
|
||||
for t in xrange x.len():
|
||||
h[t] = the_step(x[t])
|
||||
```
|
||||
|
||||
With Fluid, the training loop and the RNN in the above program are not really Python loops, but just a "loop structure" provided by Fluid and implemented in C++ as the following:
|
||||
|
||||
```python
|
||||
train_loop = layers.While(cond)
|
||||
with train_loop.block():
|
||||
m = read_minibatch()
|
||||
x = m["sentence"]
|
||||
rnn = layers.While(...)
|
||||
with rnn.block():
|
||||
h[t] = the_step(input[t])
|
||||
```
|
||||
|
||||
An actual Fluid example is described [here](https://github.com/PaddlePaddle/Paddle/blob/a91efdde6910ce92a78e3aa7157412c4c88d9ee8/python/paddle/v2/fluid/tests/test_while_op.py#L36-L44).
|
||||
|
||||
From the example, the Fluid programs look very similar to their PyTorch equivalent programs, except that Fluid's loop structure, wrapped with Python's `with` statement, could run much faster than just a Python loop.
|
||||
|
||||
We have more examples of the [`if-then-else`](https://github.com/PaddlePaddle/Paddle/blob/develop/doc/design/if_else_op.md) structure of Fluid.
|
||||
|
||||
## Turing Completeness
|
||||
|
||||
In computability theory, a system of data-manipulation rules, such as a programming language, is said to be Turing complete if it can be used to simulate any Turing machine. For a programming language, if it provides if-then-else and loop, it is Turing complete. From the above examples, Fluid seems to be Turing complete; however, it is noteworthy to notice that there is a slight difference between the `if-then-else` of Fluid and that of a programming language. The difference being that the former runs both of its branches and splits the input mini-batch into two -- one for the True condition and another for the False condition. This hasn't been researched in depth if this is equivalent to the `if-then-else` in programming languages that makes them Turing-complete. Based on a conversation with [Yuang Yu](https://research.google.com/pubs/104812.html), it seems to be the case but this needs to be looked into in-depth.
|
||||
|
||||
## The Execution of a Fluid Program
|
||||
|
||||
There are two ways to execute a Fluid program. When a program is executed, it creates a protobuf message [`ProgramDesc`](https://github.com/PaddlePaddle/Paddle/blob/a91efdde6910ce92a78e3aa7157412c4c88d9ee8/paddle/framework/framework.proto#L145) that describes the process and is conceptually like an [abstract syntax tree](https://en.wikipedia.org/wiki/Abstract_syntax_tree).
|
||||
|
||||
There is a C++ class [`Executor`](https://github.com/PaddlePaddle/Paddle/blob/develop/paddle/framework/executor.h), which runs a `ProgramDesc`, similar to how an interpreter runs a Python program.
|
||||
|
||||
Fluid is moving towards the direction of a compiler, which is explain in more detail later in this article.
|
||||
|
||||
## Backward Compatibility of Fluid
|
||||
|
||||
Given all the advantages from the removal of the concept of a *model*, hardware manufacturers might still prefer the existence of the concept of a model, so it would be easier for them to support multiple frameworks all at once and could run a trained model during inference. For example, Nervana, a startup company acquired by Intel, has been working on an XPU that reads the models in the format known as [n-graph](https://github.com/NervanaSystems/ngraph). Similarly, [Movidius](https://www.movidius.com/) is producing a mobile deep learning chip that reads and runs graphs of operators. The well-known [ONNX](https://github.com/onnx/onnx) is also a file format of graphs of operators.
|
||||
|
||||
For Fluid, we can write a converter that extracts the parts in the `ProgramDesc` protobuf message, converts them into a graph of operators, and exports the graph into the ONNX or n-graph format.
|
||||
|
||||
## Towards a Deep Learning Language and the Compiler
|
||||
|
||||
We can change the `if-then-else` and loop structure a little bit in the above Fluid example programs, to make it into a new programming language, different than Python.
|
||||
|
||||
Even if we do not invent a new language, as long as we get the `ProgramDesc` message filled in, we can write a transpiler, which translates each invocation to an operator, into a C++ call to a kernel function of that operator. For example, a transpiler that weaves the CUDA kernels outputs an NVIDIA-friendly C++ program, which can be built using `nvcc`. Another transpiler could generate MKL-friendly code that should be built using `icc` from Intel. More interestingly, we can translate a Fluid program into its distributed version of two `ProgramDesc` messages, one for running on the trainer process, and the other one for the parameter server. For more details of the last example, the [concurrent programming design](concurrent_programming.md) document would be a good pointer. The following figure explains the proposed two-stage process:
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 108 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 33 KiB |
|
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 13 KiB |
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
|
Before Width: | Height: | Size: 18 KiB After Width: | Height: | Size: 18 KiB |
|
Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 10 KiB |
@ -0,0 +1,65 @@
|
||||
# Design Doc: NCCL support in Paddle Fluid
|
||||
|
||||
## Abstract
|
||||
|
||||
This Design Doc refers to the NCCL feature in paddle. We propose an approach to support NCCL library both on a single machine and multiple machines. We wrapper the NCCL primitives `Broadcast`, `Allreduce`, `Reduce` as operators to utilize Multi-GPU powers in one script.
|
||||
|
||||
|
||||
## Motivation
|
||||
|
||||
[NCCL](https://developer.nvidia.com/nccl) is a NVIDIA library support Multi-GPU communicating and optimized for NVIDIA GPUs, it provides routines such as all-gather, all-reduce, broadcast, reduce, reduce-scatter, that can achieve high bandwidth over PCIe and NVLink high-speed interconnect. With NCCL library, we can easily accelerate the training in parallel.
|
||||
|
||||
- Pros
|
||||
1. easily plug-in with [NCCL2](https://developer.nvidia.com/nccl) library.
|
||||
1. high performance in NVIDIA GPUs.
|
||||
1. MPI like primitives, which have low learning cost for users.
|
||||
|
||||
- Cons
|
||||
1. Only design for NVIDIA GPUs, not a general multi-device solution.
|
||||
1. Although NCCL1 is opensourced under BSD license, but NCCL2 is not opensourced anymore.
|
||||
|
||||
At the beginning of training, the framework needs to distribute the same parameters to every GPU, and merge the gradients at any time user interests.
|
||||
|
||||
As a result, during training, we need the operations of peer to peer copy between different GPUs, aggregating gradients/parameters from GPUs, and broadcasting parameters to GPUs. Every GPU only need to run the operator with correct place information.
|
||||
|
||||
Besides, it needs interfaces to synchronize model update with each different GPU Cards.
|
||||
|
||||
## Implementation
|
||||
|
||||
As mentioned above, we wrap the NCCL routines as several kinds of operators. Need to note that NCCL need to create Communicator between gpu at the beginning, so there is a NCCLInit operator created.
|
||||
|
||||
### Transpiler
|
||||
|
||||
To be compatible with [parameter server design doc](https://github.com/PaddlePaddle/Paddle/blob/develop/doc/design/ops/dist_train.md), the transpiler compiles the user defined operation graph into sub-graphs to be executed on different devices.
|
||||
|
||||
1. The user-defined model will be a single device program
|
||||
|
||||
2. Broadcast/Reduce operators between GPUs will be inserted into the program, even for the multi-node, may insert the `Send`, `Recv` operator.
|
||||
|
||||
*Broadcast, AllReduce in a single machine. And Broadcast, AllReduce, [Send, Recv](https://github.com/PaddlePaddle/Paddle/blob/develop/doc/design/ops/dist_train.md#graph-converter) in multiple machines*
|
||||
|
||||
<img src="images/multigpu_before_convert.png" width="300"/>
|
||||
|
||||
After compiling, the graph as shows
|
||||
|
||||
<img src="images/multigpu_allreduce.png" width="1000"/>
|
||||
|
||||
Operators are added to the sub-graphs. Every GPU assigned a role of `rank0`, `rank1` etc.
|
||||
|
||||
- **Broadcast**. Broadcast operator distribute initialized parameter to all the GPUs from the GPU who owns it. e.g. from`rank0` GPU.
|
||||
- **AllReduce**. AllReduce operator synchronizes parameters/gradients between GPUs. AllReduce implemented in the Ring-Based communicating method, avoid of the bottle neck in a single GPU.
|
||||
|
||||
Need to notice that AllReduce operator force GPUs synchronized at that point. The whole training process in asynchronous or synchronous mode depends on the AllReduce point in the graph.
|
||||
|
||||
As it shown in the picture, when each GPU compute the gradient of `W`, followed with a `AllReduce` operator, accumulate the `dW` to full batch of data, then run the optimize process individually and apply the gradient to its `W`.
|
||||
|
||||
- **AllReduce**
|
||||
Need to note that our AllReduce operator is a ring-base AllReduce implementation. If we use the NCCL2 AllReduce primitive, every GPU optimized full batch of data, wasted (n-1) GPU compute resources. In addition, NCCL2 built-in AllReduce will only utilize the communicating resource during synchronization, then update the gradient will be a subsequent phase. In fact, we can amortize the update gradient time cost into the communicating phase. The process is
|
||||
1. Every parameter has its root card. That card will responsible for aggregating the gradients from GPUs.
|
||||
2. The whole model's parameter will be hashed to different root card, ensure the load balance between GPUs.
|
||||
3. Logically neighberhood card will start send parameter to the next one. After one round, the parameter main card will aggregate the full gradients.
|
||||
4. Then the root card will optimize the parameter.
|
||||
5. This parameter card will send its optimized result to its neighberhood, then the neighberhood will send parameter to its next one.
|
||||
6. Finish the sychronization round.
|
||||
|
||||
The total time cost will be 2 * (n-1) * per-parameter-send-time, we reach the goal of amortize the upgrade time into communicating phase.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in new issue