[6/N] Add update in module #11533
[6/N] Add update in module #11533
Conversation
- Expose the update API in module. Inside the module. invoke the method. Update API - Did a bit refactor for the `StubBackend` test code, such that it can shared between `backend_interface_update_test.cpp` and `module_test.cpp` Differential Revision: [D76172680](https://our.internmc.facebook.com/intern/diff/D76172680/) [ghstack-poisoned]
cccclai
requested review from
larryliu0820,
kirklandsign,
JacobSzwejbka,
lucylq,
swolchok and
shoumikhin
as code owners
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/11533
Note: Links to docs will display an error until the docs builds have been completed. ❌ 27 New Failures, 2 Unrelated FailuresAs of commit f0c47a6 with merge base f7cc72f ( NEW FAILURES - The following jobs have failed:
BROKEN TRUNK - The following jobs failed but were present on the merge base:👉 Rebase onto the `viable/strict` branch to avoid these failures
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
facebook-github-bot
added
the
CLA Signed
This PR needs a
|
|
This pull request was exported from Phabricator. Differential Revision: D76172680 |
- Expose the update API in module. Inside the module. invoke the method. Update API - Did a bit refactor for the `StubBackend` test code, such that it can shared between `backend_interface_update_test.cpp` and `module_test.cpp` Differential Revision: [D76172680](https://our.internmc.facebook.com/intern/diff/D76172680/) [ghstack-poisoned]
|
This pull request was exported from Phabricator. Differential Revision: D76172680 |
| runtime::Error Module::update( | ||
| const std::string& method_name, | ||
| runtime::ArrayRef<runtime::Entry> backend_options) { | ||
| ET_CHECK_OK_OR_RETURN_ERROR(load_method(method_name)); | ||
| auto& method = methods_.at(method_name).method; | ||
| return method->update(backend_options); | ||
| } | ||
|
|
There was a problem hiding this comment.
This is exactly my problem. none of the piping being done here is module or method name specific. Because the options being sent down are to the global singleton of backend. It would make sense only if we have a way to set options on an instance of the backend class that is tied to a given method and model.
Also I apologize if this was already discussed in review. It has been a while so likely I forgot
There was a problem hiding this comment.
I think we want to provide backend flexibility to decide whether it's global or per session. There is one single instance of the backend class. It is a singleton and processes all the .pte files (including all methods) even from different processes. We want the backend to have the option as needed.
Additionally, currently users don't interact with backend directly, Users just load the .pte file, construct the method. ET runtime is responsible for passing the information between user and the backends.
There was a problem hiding this comment.
I think we want to provide backend flexibility to decide whether it's global or per session.
I think these would need to be different apis. Otherwise it seems like a huge nightmare for users to reason about what options are local state and what are global. Its not also that easy to debug since ET allows closed source delegates.
Additionally, currently users don't interact with backend directly, Users just load the .pte file, construct the method.
Yeah but since the current backend api is primarily driven towards setting global state, I think it would be more natural for there to be some ET global api for them to call.
Also as an aside these options sort of feel similar to contextGuards in regular torch like inference mode. Maybe we should explore that as an api option here (not sure how portable it is especially since wed want them to be thread local.
- Expose the update API in module. Inside the module. invoke the method. Update API - Did a bit refactor for the `StubBackend` test code, such that it can shared between `backend_interface_update_test.cpp` and `module_test.cpp` Differential Revision: [D76172680](https://our.internmc.facebook.com/intern/diff/D76172680/) [ghstack-poisoned]
|
This pull request was exported from Phabricator. Differential Revision: D76172680 |
Pull Request resolved: pytorch/executorch#11533 - Expose the update API in module. Inside the module. invoke the method. Update API - Did a bit refactor for the `StubBackend` test code, such that it can shared between `backend_interface_update_test.cpp` and `module_test.cpp` ghstack-source-id: 290372284 @exported-using-ghexport Differential Revision: [D76172680](https://our.internmc.facebook.com/intern/diff/D76172680/)
| */ | ||
| ET_EXPERIMENTAL ET_NODISCARD runtime::Error update( | ||
| const std::string& method_name, | ||
| runtime::ArrayRef<runtime::Entry> backend_options); |
There was a problem hiding this comment.
I dont think we should expose arrayref options in Module. You should just skip to the syntactic sugar vector/map version you have in the next PR.
Unrelated to this PR but similar motivations to why I dont want ArrayRef here. I think its probably a mistake we used EValue in module. I wish we had a different type like extension/OwningEValue or something that let us include Dict and List for unflattened IO and let us have stronger ownership semantics on module IO cc @shoumikhin
There was a problem hiding this comment.
Similarly Im not sure its valuable to have module return Error vs throwing exception
Stack from ghstack (oldest at bottom):
StubBackendtest code, such that it can shared betweenbackend_interface_update_test.cppandmodule_test.cppDifferential Revision: D76172680