-
Notifications
You must be signed in to change notification settings - Fork 654
[6/N] Add update in module #11533
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
base: gh/cccclai/26/base
Are you sure you want to change the base?
[6/N] Add update in module #11533
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -466,6 +466,32 @@ class Module { | |
return set_output("forward", std::move(output_value), output_index); | ||
} | ||
|
||
/** | ||
* EXPERIMENTAL: Updates backend options for a specific method. | ||
* Loads the program and method before updating if needed. | ||
* | ||
* @param[in] method_name The name of the method to update. | ||
* @param[in] backend_options The backend options to update the method with. | ||
* | ||
* @returns An Error to indicate success or failure. | ||
*/ | ||
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Similarly Im not sure its valuable to have module return Error vs throwing exception |
||
|
||
/** | ||
* EXPERIMENTAL: Updates backend options for the 'forward' method. | ||
* Loads the program and method before updating if needed. | ||
* | ||
* @param[in] backend_options The backend options to update the method with. | ||
* | ||
* @returns An Error to indicate success or failure. | ||
*/ | ||
ET_EXPERIMENTAL ET_NODISCARD inline runtime::Error update( | ||
runtime::ArrayRef<runtime::Entry> backend_options) { | ||
return update("forward", backend_options); | ||
} | ||
|
||
/** | ||
* Retrieves the EventTracer instance being used by the Module. | ||
* EventTracer is used for tracking and logging events during the execution | ||
|
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.