-
Notifications
You must be signed in to change notification settings - Fork 48
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
Update "Performance Adaptation" use case #207
Closed
Closed
Changes from 1 commit
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 wording seems to imply that WebNN is responsible for automatically pick "the best" option to accelerate a given model based on what is available on the platform without necessarily relying on the input from either the web application or the framework that uses it. This is a big requirement that goes beyond simply:
as it also involves analyzing model's complexity and memory bandwidth requirements, etc. Also note that "best" is subjective e.g. is it best for inference latency, data throughput, or battery life?
I understand that this is a new use case. I just want to flag that this may be a design requirement that we have yet to agree as one of the design goals.
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.
Thanks for the comment. We revised the use case for reflecting the comment.
The descriptions of automatic switching function are revised with considerations of user's preference. In the revised use-case, the 'best' option for the user can be subjectively changed by user's preference.
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.
Thanks for addressing my question. But I'm still not sure I fully understand this use case. Are we saying that the use case is for a framework to use WebNN for transfer learning on the user-machine via the web browser?
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.
First of all, thanks for your good catch!
Unfortunately, we missed to consider the web browser scenario when we discussed this issue. We just focused the scenario for implementing DNN model in the mobile devices. Actually, the automatic selection of hardware in mobile devices are being researched in point of view for designing the mobile chip product such as Qualcom's snapdragon.
During several months, we investigated automatic hardware selection in web browser to resolve your sharp question. However, this is very premature issue to implement with the above approach. Just checking the hardware capability is not enough to implement automatic hardware selection function and it seems that this function may be related with ML model-specific matter rather than hardware-specific matter.
To deal with automatic hardware selection, web application developer may need to measure their DNN model performance by using the benchmark framework such as tensorflow benchmark library. See this reference Tensorflow's Performance measurement, and issue #169.
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.
Thank you @spshin3 for the revised use case.
Do you think the proposed "Performance Benchmark" use case (as in this PR) would benefit from additional API surface or features in the WebNN API? There's a separate Battery Status API that may address your requirements related to identifying when the battery of the user's device is charging or the device is plugged in. I think these two APIs used together might help address your use case.
Feel free to follow up with your suggestions in #169 for any device preference hints or similar features that'd help this use case. Or if changes would be suggested to the Battery Status API, feel free to file issues for that spec.
Thank you for your continued contributions!
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.
Thanks for carefull reviewing again! @wchao1115
I think that the 'option 2' is similar with our intention for the functionality of 'benchmark'.
If some developers want to test across different hardware like option1, they needs to set each target configuration of ardware offline.
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.
Given 'option 2', it looks like we could update the existing use case https://www.w3.org/TR/webnn/#usecase-perf-adapt
My assumptions are that the web developer may want to:
Or we can do both.
I tried to incorporate these approaches into the existing use case merging with @spshin3's use case, proposal:
WDYT @spshin3? Suggestions welcome!
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 fully agreed @anssiko 's comment because we changed our approach now (automatic device selection -> test device performance).
I reflected the comment by revising our proposal. Please check the new version!
Thanks @anssiko @wchao1115 !
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.
@anssiko The text that you propose here is still unclear to me. The wording makes it hard to understand what it tries to say. I don't know how to help because I may misrepresent it.
If we go with my wild guess of #2 above, then the issue we should consider is whether WebNN is the right API to "test" that whether a specific type of accelerator is available in the system it currently runs on. And even if it could, the presence of certain accelerator in the system doesn't necessarily imply the performance of the model being run on it. I just can't see the WebNN API as the right API for this purpose.
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.
@wchao1115 I think I understand your concerns. My proposal was too idealistic.
A concern that I stated earlier but failed to factor into this latest proposal was that the device selection is a hint in part due to privacy reasons. Now, I think that alone might make this use case not possible to be implemented reliably.
Then, if we in addition consider "the presence of certain accelerator in the system doesn't necessarily imply the performance of the model being run on it" I'm afraid the use case is not practical.
I don't immediately see how we could change the API to better cater for this use case while retaining its privacy-preserving qualities. @spshin3 thoughts?
Should we drop the existing performance adaption use case entirely?