Skip to content

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

Merged
merged 6 commits into from
Oct 7, 2020
Merged

Update model execution API #94

merged 6 commits into from
Oct 7, 2020

Conversation

wchao1115
Copy link
Collaborator

@wchao1115 wchao1115 commented Sep 28, 2020

  1. Support optional outputs and optional input shapes. (Model Execution API #87)
  2. Model builder interface for state separation between context state and graph state. (Model Execution API #87)
  3. Fold the execution interface into the compilation interface for simplicity. (Model Execution API #87)
  4. Remove quantization-related params from the operand descriptor. (Remove quantization-specific params from OperandDescriptor #44)
  5. Simplify operand type enum. (Model Execution API #87)
  6. Update URL references of first-wave operators. (Evaluate noise suppression models for required ops #66)
  7. Update spec code samples and comments accordingly.

@gramalingam


Preview | Diff

…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.
Copy link
Contributor

@huningxin huningxin left a 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.
Copy link
Contributor

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: []}.

Copy link
Collaborator Author

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.

Copy link
Contributor

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.
@huningxin
Copy link
Contributor

Another thing is whether we need to change the informative sample code where nn is used. e.g. for relu, the sample code is

return nn.max(nn.constant(0), x);

Copy link
Contributor

@huningxin huningxin left a 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)),
Copy link
Contributor

@huningxin huningxin Oct 1, 2020

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.

Copy link
Collaborator Author

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 = {});
Copy link
Collaborator

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?

Copy link
Collaborator Author

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?

Copy link
Contributor

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?

Copy link
Collaborator Author

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.

Copy link
Contributor

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.

Copy link
Collaborator Author

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.

Copy link
Contributor

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.

@anssiko
Copy link
Member

anssiko commented Oct 6, 2020

@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!

@wchao1115 wchao1115 merged commit 65772f1 into master Oct 7, 2020
@wchao1115 wchao1115 deleted the wchao/execution_api_change branch October 7, 2020 05:55
@zolkis
Copy link
Collaborator

zolkis commented Oct 7, 2020

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(
Copy link
Collaborator

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(...))

Copy link
Contributor

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.

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.

5 participants