-
Notifications
You must be signed in to change notification settings - Fork 81
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
[RFC][MLF] Model Library Format with Multiple Modules #76
Conversation
ef7a760
to
90e829f
Compare
90e829f
to
d492d22
Compare
Discussion in the community meeting was pretty supportive! Some summary notes:
|
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.
@mehrdadh Thanks for the RFC. Looks good!
Just some nits and I have a couple of questions for clarification and my own (better) understanding.
Cheers.
[guide-level-explanation]: #guide-level-explanation | ||
|
||
Users call `export_model_library_format` function with multiple Relay builds (output from `tvm.relay.build`) or | ||
single a Relay build module. We change the `export_model_library_format` API to support multiple Relay Build, however |
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.
s/single a/a single/?
Also, maybe say "Users will call export_model_library_format
function ... or a single Relay build module?"
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.
done.
it is backward compatible and, we handle required changes internally. | ||
|
||
Since we are including multiple modules in a single MLF file, we need to make some changes. Let's assume we | ||
are want to export MLF file for two Relay build modules called `mod1` and `mod2`. |
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.
d/are/
Maybe "...export A MLF file WITH two Relay build modules..."? Just a suggestion.
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.
done.
} | ||
``` | ||
2. There are multiple Relay text file generated per each Relay build. We propose to structure these files by using | ||
module name and `.relay` extension to differentiate its format(E.g. {`mod1.relay`, `mod2.relay`, ...}). Similarly, for |
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.
Just for clarification, does it mean that src/relay.txt
won't exist anymore in this new version and will be replaced by mod1.relay
, modN.delay
, ... but nothing changes for the current (old) version (i.e. relay.txt will still exist)? Either way maybe it's worth mentioning what changes/doesn't change regarding src/relay.txt
.
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.
By old version if you mean MLF version 6, yes we are not changing that. However, for the new version we are changing relay.txt
to MOD_NAME.relay
```javascript | ||
{ | ||
'modules': { | ||
'mod1': { |
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.
Could you please clarify which structures will be moved inside 'modN': {} level in this new version? I'm wondering about memory
, functions
, and operator_functions
...
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.
added more details to the RFC. Everything would be the same as before except version which will remain at top level.
|
||
The drawback here is that we are changing generated metadata and file structure in the MLF file which means external | ||
tools which are dependent to this need to update their tool. Hopefully this RFC makes it clear on what steps they need | ||
to take. |
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.
Since we'are updating the "version"
field I think any dependency/tool can adapt to the new MLF version smoothly.
# **Rationale and alternatives** | ||
An alternative way to implement this feature is to break down each Relay build module to a subdirectory and keep the | ||
previous format inside each sub Relay build module. Using the example of `mod1` and `mod2`, in this approach we have | ||
an MLF file format with structure bellow if we extract: |
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.
nit: below
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.
done.
mod.relay | ||
``` | ||
|
||
One of the benefits of this approach is that create a more readable file structure which is modularized for |
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.
nit. s/is that create/is that is creates/?
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.
should be is that is creates
I think. I changed it to that.
``` | ||
|
||
One of the benefits of this approach is that create a more readable file structure which is modularized for | ||
each Relay build module. However, the downside is that this approach will result in more modifications in project |
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.
Really can't find any issue with proposed dir. structure. Also to me it isn't such a great benefit for readability breaking down the modules in separate subdirs tbh.
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 agree, I think it will add more complexity to the build process.
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.
@gromero thanks for the review! I addressed your comments. PTAL
[guide-level-explanation]: #guide-level-explanation | ||
|
||
Users call `export_model_library_format` function with multiple Relay builds (output from `tvm.relay.build`) or | ||
single a Relay build module. We change the `export_model_library_format` API to support multiple Relay Build, however |
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.
done.
it is backward compatible and, we handle required changes internally. | ||
|
||
Since we are including multiple modules in a single MLF file, we need to make some changes. Let's assume we | ||
are want to export MLF file for two Relay build modules called `mod1` and `mod2`. |
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.
done.
```javascript | ||
{ | ||
'modules': { | ||
'mod1': { |
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.
added more details to the RFC. Everything would be the same as before except version which will remain at top level.
} | ||
``` | ||
2. There are multiple Relay text file generated per each Relay build. We propose to structure these files by using | ||
module name and `.relay` extension to differentiate its format(E.g. {`mod1.relay`, `mod2.relay`, ...}). Similarly, for |
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.
By old version if you mean MLF version 6, yes we are not changing that. However, for the new version we are changing relay.txt
to MOD_NAME.relay
# **Rationale and alternatives** | ||
An alternative way to implement this feature is to break down each Relay build module to a subdirectory and keep the | ||
previous format inside each sub Relay build module. Using the example of `mod1` and `mod2`, in this approach we have | ||
an MLF file format with structure bellow if we extract: |
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.
done.
mod.relay | ||
``` | ||
|
||
One of the benefits of this approach is that create a more readable file structure which is modularized for |
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.
should be is that is creates
I think. I changed it to that.
``` | ||
|
||
One of the benefits of this approach is that create a more readable file structure which is modularized for | ||
each Relay build module. However, the downside is that this approach will result in more modifications in project |
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 agree, I think it will add more complexity to the build process.
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.
@mehrdadh Thanks for expanding the example for the new structure. LGTM.
This RFC proposes adding multiple module support in Model Library Format.
cc @gromero @areusch