Support the execution of the sub-graph scenario

[huningxin]

Opening this issue to follow up the discussion of #94 (comment).

@pyu10055 mentioned:

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?

Actually, the existing builder.createModel allows to specify the outputs. With that, developers could create different sub-graphs (models) from a topology within a builder and compile/compute them individually. For example:

const builder = nn.createModelBuilder();
const a = builder.input('a', descA);
const b = builder.constant(descB, bufferB);
const c = builder.constant(descC, bufferC);
const d = builder.mul(a, b);
const e = builder.add(d, c);
const model1 = builder.createModel({d}); // d = a * b
const model2 = builder.createModel({e}); // e = a* b + c

@pyu10055 , please let us know any gaps of the existing API and share more details of your proposal. Thanks!

[huningxin]

Hi @pyu10055 , this issue was discussed in 10/29 WebML CG call. The participants would like to know more about your use case and understand the gaps. Could you please elaborate it a bit more? Thanks!

[pyu10055]

This API allows users to specify two models with different output nodes. I think it should be ok for the purpose of transfer learning. But this API does not seem to follow the conventional builder pattern, where the final export API would not change the structure of the built object. It feels more natural to build a single model, but compile into two execution plans using the compile method.

[anssiko]

Per earlier discussion it seems the major use cases are addressed with the existing API. I'll close this issue but please feel free to re-open if new information is made available that suggests otherwise.

I have updated the 2021-01-07 agenda accordingly.