Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design doc of compile time register gradient operators #4517

Merged

Conversation

reyoung
Copy link
Collaborator

@reyoung reyoung commented Sep 29, 2017

No description provided.

@reyoung reyoung force-pushed the feature/design_doc_of_new_grad_op branch 2 times, most recently from 52fec02 to 12713e9 Compare September 29, 2017 20:48

## Problem

Since we separate users program in two stages, compile time and runtime, we should record and look up the mapping relationship between an operator and its gradient operators when compile. However, we register this relationship in runtime by these `OpInfo` fields.
Copy link
Member

@QiJune QiJune Sep 29, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The execution of a neural network topology in PaddlePaddle is separated into two stages, complie-time and run-time.
At complie-time, a ProgramDesc will be generated. At run-time, the ProgramDesc will be executed on specific hardware. We can refer to the design of computation-graphs.
The Gradient Operator's OpDesc is also generated at compile-time. We have to find the mapping relationship between Operator's OpDesc and its GradientOp's OpDesc.
However, we make the mapping relationship between Operator and its GradientOp at run-time in OpInfo class currently.


## Problem

Since we separate users program in two stages, compile time and runtime, we should record and look up the mapping relationship between an operator and its gradient operators when compile. However, we register this relationship in runtime by these `OpInfo` fields.
Copy link
Collaborator

@wangkuiyi wangkuiyi Sep 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Problem Posed

In our current operator registration mechanism, for each operator, the programmer should register a gradient operator creator function, which takes a C++ operator instance, and returns the corresponding gradient instance.

However, as we decided to separate the compilation and execution of DL models, we need to reshape the creator to take a protobuf OpDesc message, and returns a corresponding message.

More than that, the new registration mechanism need to support the fact that an operators' gradient computation might be a composition of operators.

Current Implementation

Proposed Solution

@reyoung reyoung merged commit f76b38c into PaddlePaddle:develop Sep 30, 2017
@reyoung reyoung deleted the feature/design_doc_of_new_grad_op branch October 2, 2017 18:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants