Indeed it is a tradeoff, and in this case there can certainly be multiple
choices. The key problem we want to answer is how do we want to expose pass
"symbol" of meta data to each engine. This is an important topi as it can
affect the serialization convention of our future packages, let us think a bit
more about it.
To faciliate the discussion, let us think the following scenario
```
fn mymodule(%y) {
let subfunc0 = (%x: Tensor[(10, 10)]) {
%1 = meta[Constant][0]
%2 = meta[Constant][1]
(%x + %1) * %2
}
let subfunc1 = (%x: Tensor[(10, 10)]) {
%2 = meta[Constant][0]
%x * %2
}
let subfunc2 = (%x: Tensor[(10, 10)]) {
%3 = meta[Constant][1]
%x / %3
}
%1 = %subfunc0(%y)
%2 = %subfunc1(%1)
%3 = %subfunc2(%2)
%3
}
```
The resulting module can be seen as follows:
```
metadatamodule (stores constant 0, 1, 2 and need to pass them to be module)
- sourcemodule0(contains subfunc0, subfunc1)
- sourcemodule1(contains subfunc2)
```
Our design choices include different ways to pass in these constants(metadata).
The choices include:
- C0: Uniquely name the "symbol" of each constant globally in the module
- Pass by calling `set_module_param(String name, NDArray)`
- C1: Uniquely name the "function" of each module, and pass initializers for
each function.
- `init_mod0_subfunc0({const0, const1})`, `init_mod1_subfunc1({const0})`
- C2: Uniquely name each module(module0, module1)
- call `init_module0(Map<String, Object/NDArray>)`
Each of the choices have certain pros and cons in terms of the following aspect:
- API simplicity(Map does comes with an overhead).
- The ability to see all required params in an engine(before calling setup
functions),for example in subfunc0 may need to see const0, and const1 in order
to setup its engine.
- Consistency with the function naming convention: due to the restriction of
DSO engine, we simply use one-level string to map from name to functions.
Finally, it is important to consider the following aspect of module
combination. In the final linking stage, sourcemodule0 and sourcemodule1 goes
into the same DSO library. This means we cannot use the same initialize
function for them, and need to have a unique name for their initialization
function.
---
[Visit
Topic](https://discuss.tvm.ai/t/byoc-runtime-json-runtime-for-byoc/6579/24) to
respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.ai/email/unsubscribe/5ded9c18f5a991238f3cd99ce82db83a5ebff136e759bef9f0fd5be3c9d1ea4e).
