-
Notifications
You must be signed in to change notification settings - Fork 51
Update model execution API #94
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
Conversation
…uilder interface for state separation between context and graph state. Fold the execution interface into the compilation interface for simplicity. Remove quantization-related params from the operand descriptor. Simplify operand type enum. Update code examples and comments accordingly. Update URL references of first-wave operators.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wchao1115 , thanks for your great work. I left some comments, please take a look.
@@ -217,13 +213,6 @@ dictionary OperandDescriptor { | |||
// The dimensions field is only required for tensor operands. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we are going to remove the tensor-type
values of OperandType
, we may need to define how to define a scalar. The options are no dimensions
member, e.g. {type: 'float32'}
or empty dimensions
, e.g. {type: 'float32', dimensions: []}.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I plan to open a new issue on scalar tensor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
…Operands, Inputs and Outputs to NamedOperands, NamedInputs, and NamedOutputs. Update URL links of the first-wave operators doc.
Another thing is whether we need to change the informative sample code where return nn.max(nn.constant(0), x); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Thanks @wchao1115 .
index.bs
Outdated
builder.mul( | ||
builder.reshape(scale, shape), | ||
builder.div( | ||
builder.sub(input, reshape(mean, shape)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one nit: should it be builder.reshape
? it was an old issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
@@ -1033,23 +1031,29 @@ dictionary CompilationOptions { | |||
}; | |||
|
|||
interface Model { | |||
Promise<Compilation> createCompilation(optional CompilationOptions options = {}); | |||
Promise<Compilation> compile(optional CompilationOptions options = {}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With this API, the computation is tied with the compilation. should the compile method have the inputs/outputs pair and execution can only execution the graph compiled with the input/output pair? Otherwise, the compilation might not support the execution of the sub-graph scenario?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pyu10055 Good idea. Will this work now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need this change?
@pyu10055 , according to #87 (comment), you seemed to agree the Promise<NamedOutputs> compute(NamedInputs inputs, optional NamedOutputs outputs);
(the ability to specify the outputs when executing) would support the sub-graph execution use case, correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@huningxin I actually do not recommend partial execution of a compiled graph as any operator in between the input and output operands may be folded with the surrounding operators from fusions or even eliminated by constant folding. The only guaranteed executable operands are the input and the output operands of the compiled graph. Partial compilation of a model is much more robust. Once a compilation is produced for the partial model, it stays valid and can be executed as such.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wchao1115 , I only mean the compute
method now allows developers to select the output operands of a compiled graph. I didn't recommend the partial execution for any intermediate operands between inputs and outputs.
My point is that the graph building is in the context of new ModelBuilder
object. Developers are free to create a sub-graph by createModel
API and compile/execute it. I think it would support the sub-graph execution use case without adding inputs/outputs pair to compile
method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@huningxin and I discussed this specific change offline. We want to track partial graph execution as a separate issue. @pyu10055 you may create a new issue just for this topic if you wish. I will now complete this PR with the original set of changes as outlined in the PR description above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created #105 as follow-up.
@pyu10055 PTAL. This is the last call for comments prior to merging this PR. Please provide your feedback by Pacific Time afternoon today. We'd like to get this PR landed to unblock other pending changes. Thanks! |
Good changes, helps clarity. |
nn.div( | ||
nn.sub(input, reshape(mean, shape)), | ||
nn.sqrt(nn.add(nn.reshape(variance, shape), nn.constant(epsilon))) | ||
return builder.add( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ideally it would be great to allow chained api for the Operands.
builder.constant(...).add(builder.constant(...))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a good idea. Created #106 to follow up.
@gramalingam
Preview | Diff