-
Notifications
You must be signed in to change notification settings - Fork 25.6k
[dynamo][guards] Use DATA_PTR instead of ID_MATCH for tensors #123302
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
Closed
Conversation
This file contains hidden or 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
[ghstack-poisoned]
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/123302
Note: Links to docs will display an error until the docs builds have been completed. ✅ You can merge normally! (1 Unrelated Failure)As of commit 5601f90 with merge base 4732375 ( FLAKY - The following job failed but was likely due to flakiness present on trunk:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
mlazos
approved these changes
Apr 3, 2024
pytorchmergebot
pushed a commit
that referenced
this pull request
Apr 4, 2024
pytorchmergebot
pushed a commit
that referenced
this pull request
Apr 5, 2024
…cessor (#123396) Speeds up the guard-overhead microbenchmark by around 10% normalized to main-branch CPP guards ~~~ import torch @torch.compile(backend="eager") def fn(x, lst): for l in lst: x = x + l return x n = 1000 lst = [i for i in range(n)] x = torch.randn(4) print(fn(x, lst)) print("Sucess") ~~~ Pull Request resolved: #123396 Approved by: https://github.com/jansel ghstack dependencies: #123285, #123302, #123303
Note for oncall @shunting314 - If you end up bisecting this to be a source of a regression, this is fwd fixed here - #123485 |
pytorchmergebot
pushed a commit
that referenced
this pull request
Apr 6, 2024
For some reason, adding a `TYPE_CHECK` in DATA_PTR_MATCH guard in #123302 increases optimizer guard overhead for `MT5ForConditionalGeneration` by 10x. There is nothing special about MT5. As we are going to move towards the CPP guards soon, there is no reason to investigate this deeper. We can use `ID_MATCH` instead of `DATA_PTR` match. Today both cant be serialized, so there is no one preference over the other. Pull Request resolved: #123485 Approved by: https://github.com/mlazos
sanketpurandare
pushed a commit
to sanketpurandare/pytorch
that referenced
this pull request
Apr 22, 2024
…h#123302) We should sparingly use ID_MATCH guards. When it comes to performance, ID_MATCH is much faster DATA_PTR for Python guards. However, the difference is very small in C++. So, its worth just using DATA_PTR_MATCH. Pull Request resolved: pytorch#123302 Approved by: https://github.com/mlazos ghstack dependencies: pytorch#123285
sanketpurandare
pushed a commit
to sanketpurandare/pytorch
that referenced
this pull request
Apr 22, 2024
Not needed since pytorch#122858 has landed Pull Request resolved: pytorch#123303 Approved by: https://github.com/mlazos ghstack dependencies: pytorch#123285, pytorch#123302
sanketpurandare
pushed a commit
to sanketpurandare/pytorch
that referenced
this pull request
Apr 22, 2024
…cessor (pytorch#123396) Speeds up the guard-overhead microbenchmark by around 10% normalized to main-branch CPP guards ~~~ import torch @torch.compile(backend="eager") def fn(x, lst): for l in lst: x = x + l return x n = 1000 lst = [i for i in range(n)] x = torch.randn(4) print(fn(x, lst)) print("Sucess") ~~~ Pull Request resolved: pytorch#123396 Approved by: https://github.com/jansel ghstack dependencies: pytorch#123285, pytorch#123302, pytorch#123303
sanketpurandare
pushed a commit
to sanketpurandare/pytorch
that referenced
this pull request
Apr 22, 2024
For some reason, adding a `TYPE_CHECK` in DATA_PTR_MATCH guard in pytorch#123302 increases optimizer guard overhead for `MT5ForConditionalGeneration` by 10x. There is nothing special about MT5. As we are going to move towards the CPP guards soon, there is no reason to investigate this deeper. We can use `ID_MATCH` instead of `DATA_PTR` match. Today both cant be serialized, so there is no one preference over the other. Pull Request resolved: pytorch#123485 Approved by: https://github.com/mlazos
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Stack from ghstack (oldest at bottom):
We should sparingly use ID_MATCH guards. When it comes to performance, ID_MATCH is much faster DATA_PTR for Python guards. However, the difference is very small in C++. So, its worth just using DATA_PTR_MATCH.
cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @chauhang