forked from PaddlePaddle/Paddle
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
81 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,81 @@ | ||
## Motivation | ||
|
||
There is a ```gap``` between the ```Program``` defined by | ||
user and the ```Executable``` that can be scheduled | ||
efficiently on heterogeneous hardware, either locally | ||
or distributedly. | ||
|
||
Usually, the ```gap``` is bridged by | ||
|
||
* A serious transformations with defined order. | ||
|
||
* The transformations usually invovle | ||
```insert, delete, clustering, split, dependency analysis```. | ||
|
||
* Has a simple way to verify and debug each transformation. | ||
|
||
* Flexible to add, remove or customize transformations to fit | ||
the requirements of various algorithms (models) and hardware secenarios. | ||
|
||
Some other events also push us to a better unified pattern. | ||
|
||
* The deep learning framework is built around the concepts of graphs. | ||
To leverage tools such as compilation (e.g. TVM and nGraph) or | ||
cross-framework conversion (e.g. ONNX), we also need a intermediate | ||
representation that can be connected to the rest of the ecosystem. | ||
|
||
|
||
We need a unified pattern to naturally support the requirements | ||
described above. The pattern should fit both training, inference | ||
and other offline serielized model transformations. | ||
Learned from LLVM and other deep learning framework, we draft the | ||
design below. | ||
|
||
|
||
## Design | ||
|
||
### Major Concepts | ||
|
||
#### Node | ||
|
||
```Node``` represents an operation that performs some computation or | ||
a variable that is input or output of operation. | ||
|
||
```Node```s are connected to other ```Node```s via inputs and outputs. | ||
|
||
#### Graph | ||
|
||
```Graph``` contains a list of ```Node```s. | ||
|
||
TODO: Better definitions for the graph. | ||
|
||
```Graph``` can also contain ```Attribute```s. ```Attribute```s | ||
can be ``any`` thing. For example, it can be a list of "wraper" | ||
nodes. The ```wrapper``` nodes compose ```Node```s and provide | ||
helper method for execution. ```Attribute``` can also contain | ||
other things that describe some properties of the ```Graph```. | ||
|
||
#### Pass | ||
|
||
```Pass``` represents a transformation of ```Graph```. Its input | ||
is a ```Graph``` and its output is also a ```Graph```. For example, | ||
a ```Pass``` can simply print out the ```Graph```. A ```Pass``` | ||
can also fuse some ```Graph```'s ```Node```s. | ||
|
||
#### Optimize | ||
|
||
```Optimize``` contains a series of ```Pass``` with defined order. | ||
```Optimize``` transforms a ```Graph``` that only contains raw | ||
modeling logic to a ```Graph``` that can be run efficiently while | ||
maintaining the original modeling logic. | ||
|
||
|
||
### Workflow | ||
|
||
|
||
* Program is first converted to Graph. | ||
* Graph goes through a series of Pass | ||
* Graph is transformed from raw model logic to a | ||
form that is efficient to execute. | ||
|
||
Graph->Pass1->Graph->Pass2->Graph->Pass3->Executor |