Skip to content
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

Merged
merged 2 commits into from
Jun 7, 2022

Conversation

mehrdadh
Copy link
Member

This RFC proposes adding multiple module support in Model Library Format.

cc @gromero @areusch

@mehrdadh mehrdadh force-pushed the mlf/multiple_modules branch from ef7a760 to 90e829f Compare May 31, 2022 16:25
@areusch
Copy link
Contributor

areusch commented May 31, 2022

cc @Mousius @manupa-arm @leandron

@mehrdadh mehrdadh force-pushed the mlf/multiple_modules branch from 90e829f to d492d22 Compare June 1, 2022 14:57
@driazati
Copy link
Member

driazati commented Jun 1, 2022

Discussion in the community meeting was pretty supportive! Some summary notes:

  • Name prefix option makes sense, change seems like a natural evolution of MLF
  • Before users would have to do the same thing by hand
  • Is the deserializer going to be backwards compatible?
    • No loader in C++ runtime, only in project API. Eventually MLF scope will expand to include other things like multiple devices, so C++ loader might be useful later on. Code typically used along with the same TVM revision so no need to keep around the old loader. The version number can be used to provide helpful error messages.
  • It would be good to add a description for users on what needs to change, if anything and reference documentation

Copy link
Contributor

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

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?"

Copy link
Member Author

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

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.

Copy link
Member Author

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

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.

Copy link
Member Author

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': {
Copy link
Contributor

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

Copy link
Member Author

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

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:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: below

Copy link
Member Author

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

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/?

Copy link
Member Author

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

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.

Copy link
Member Author

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.

@gromero gromero self-assigned this Jun 3, 2022
Copy link
Member Author

@mehrdadh mehrdadh left a 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
Copy link
Member Author

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`.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done.

```javascript
{
'modules': {
'mod1': {
Copy link
Member Author

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
Copy link
Member Author

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:
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member Author

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.

@mehrdadh mehrdadh requested a review from gromero June 3, 2022 17:56
Copy link
Contributor

@gromero gromero left a 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.

@gromero gromero merged commit f47c6ad into apache:main Jun 7, 2022
@mehrdadh mehrdadh deleted the mlf/multiple_modules branch June 7, 2022 19:11
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.

4 participants