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.
huningxin
left a comment
There was a problem hiding this comment.
@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.
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.
I plan to open a new issue on scalar tensor.
…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); |
huningxin
left a comment
There was a problem hiding this comment.
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.
one nit: should it be builder.reshape? it was an old issue.
|
|
||
| interface Model { | ||
| Promise<Compilation> createCompilation(optional CompilationOptions options = {}); | ||
| Promise<Compilation> compile(optional CompilationOptions options = {}); |
There was a problem hiding this comment.
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.
@pyu10055 Good idea. Will this work now?
There was a problem hiding this comment.
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.
@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.
@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.
@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.
|
@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.
ideally it would be great to allow chained api for the Operands.
builder.constant(...).add(builder.constant(...))
There was a problem hiding this comment.
I think this is a good idea. Created #106 to follow up.
@gramalingam
Preview | Diff