Make variables in dict LazyTrackers (not lazily guarded yet) and avoid using DICT_KEYS guard #117625
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
This removes the need of having to reimplement the whole builder logic to try to predict what is it that we have inside. This is marginally less efficient when we graph break, but in turn we should graph break less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`). [ghstack-poisoned]
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/117625
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit 9931d42 with merge base 4cba1dd ( This comment was automatically generated by Dr. CI and updates every 15 minutes. |
This was referenced Jan 17, 2024
lezcano
added a commit
that referenced
this pull request
Jan 17, 2024
This removes the need of having to reimplement the whole builder logic to try to predict what is it that we have inside. This is marginally less efficient when we graph break, but in turn we should graph break less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`). ghstack-source-id: f421743 Pull Request resolved: #117625
This removes the need of having to reimplement the whole builder logic to try to predict what is it that we have inside. This is marginally less efficient when we graph break, but in turn we should graph break less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`). cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 aakhundov kadeng [ghstack-poisoned]
This was referenced Jan 17, 2024
This removes the need of having to reimplement the whole builder logic to try to predict what is it that we have inside. This is marginally less efficient when we graph break, but in turn we should graph break less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`). cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 aakhundov kadeng [ghstack-poisoned]
This removes the need of having to reimplement the whole builder logic to try to predict what is it that we have inside. This is marginally less efficient when we graph break, but in turn we should graph break less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`). cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 aakhundov kadeng [ghstack-poisoned]
This removes the need of having to reimplement the whole builder logic to try to predict what is it that we have inside. This is marginally less efficient when we graph break, but in turn we should graph break less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`). cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 aakhundov kadeng [ghstack-poisoned]
This removes the need of having to reimplement the whole builder logic to try to predict what is it that we have inside. This is marginally less efficient when we graph break, but in turn we should graph break less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`). cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 aakhundov kadeng [ghstack-poisoned]
This removes the need of having to reimplement the whole builder logic to try to predict what is it that we have inside. This is marginally less efficient when we graph break, but in turn we should graph break less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`) and more correct. cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 aakhundov kadeng [ghstack-poisoned]
jansel
requested changes
Jan 17, 2024
This removes the need of having to reimplement the whole builder logic to try to predict what is it that we have inside. This is marginally less efficient when we graph break, but in turn we should graph break less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`) and more correct. cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 aakhundov kadeng [ghstack-poisoned]
This removes the need of having to reimplement the whole builder logic to try to predict what is it that we have inside. This is marginally less efficient when we graph break, but in turn we should graph break less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`) and more correct. cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 aakhundov kadeng [ghstack-poisoned]
lezcano
changed the title
Make variables in dict lazy and remove DICT_KEYS guard. We build the keys of a dict depth-first and we rely on the guards of each element in the dict to create the correct guards. This allows us to remove the rather buggy DICT_KEYS guard and make the guard lazy. The guards are not completely lazy yet, as we instantiate them in `_HashableTracker._eq_impl` but it should be possible to make them truly lazy. Also, adding new types to the supported types within keys should be less error prone. This is marginally less efficient when we graph break, but in turn we should graph break much less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`). cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 aakhundov kadeng [ghstack-poisoned]
anijain2305
approved these changes
Jan 25, 2024
…t) and avoid using DICT_KEYS guard" Make variables in dict lazy and remove DICT_KEYS guard. We build the keys of a dict depth-first and we rely on the guards of each element in the dict to create the correct guards. This allows us to remove the rather buggy DICT_KEYS guard and make the guard lazy. The guards are not completely lazy yet, as we instantiate them in `_HashableTracker._eq_impl` but it should be possible to make them truly lazy. Also, adding new types to the supported types within keys should be less error prone. This is marginally less efficient when we graph break, but in turn we should graph break much less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`). cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 aakhundov kadeng [ghstack-poisoned]
…t) and avoid using DICT_KEYS guard" Make variables in dict lazy and remove DICT_KEYS guard. We build the keys of a dict depth-first and we rely on the guards of each element in the dict to create the correct guards. This allows us to remove the rather buggy DICT_KEYS guard and make the guard lazy. The guards are not completely lazy yet, as we instantiate them in `_HashableTracker._eq_impl` but it should be possible to make them truly lazy. Also, adding new types to the supported types within keys should be less error prone. This is marginally less efficient when we graph break, but in turn we should graph break much less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`). cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 aakhundov kadeng [ghstack-poisoned]
anijain2305
reviewed
Jan 27, 2024
| self.install_guards(GuardBuilder.BOOL_FALSE) | ||
| else: | ||
| self.install_guards(GuardBuilder.DICT_KEYS) | ||
| self.install_guards(GuardBuilder.LIST_LENGTH) |
There was a problem hiding this comment.
Does it make sense to delete DICT_KEYS guard (maybe we will have to clean up at other places)?
There was a problem hiding this comment.
That's the plan, yes. I'll put up a PR next week.
…t) and avoid using DICT_KEYS guard" Make variables in dict lazy and remove DICT_KEYS guard. We build the keys of a dict depth-first and we rely on the guards of each element in the dict to create the correct guards. This allows us to remove the rather buggy DICT_KEYS guard and make the guard lazy. The guards are not completely lazy yet, as we instantiate them in `_HashableTracker._eq_impl` but it should be possible to make them truly lazy. Also, adding new types to the supported types within keys should be less error prone. This is marginally less efficient when we graph break, but in turn we should graph break much less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`). cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 aakhundov kadeng [ghstack-poisoned]
…t) and avoid using DICT_KEYS guard" Make variables in dict lazy and remove DICT_KEYS guard. We build the keys of a dict depth-first and we rely on the guards of each element in the dict to create the correct guards. This allows us to remove the rather buggy DICT_KEYS guard and make the guard lazy. The guards are not completely lazy yet, as we instantiate them in `_HashableTracker._eq_impl` but it should be possible to make them truly lazy. Also, adding new types to the supported types within keys should be less error prone. This is marginally less efficient when we graph break, but in turn we should graph break much less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`). cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 aakhundov kadeng [ghstack-poisoned]
This was referenced Jan 30, 2024
Closed
…t) and avoid using DICT_KEYS guard" Make variables in dict lazy and remove DICT_KEYS guard. We build the keys of a dict depth-first and we rely on the guards of each element in the dict to create the correct guards. This allows us to remove the rather buggy DICT_KEYS guard and make the guard lazy. The guards are not completely lazy yet, as we instantiate them in `_HashableTracker._eq_impl` but it should be possible to make them truly lazy. Also, adding new types to the supported types within keys should be less error prone. This is marginally less efficient when we graph break, but in turn we should graph break much less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`). cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 aakhundov kadeng [ghstack-poisoned]
…t) and avoid using DICT_KEYS guard" Make variables in dict lazy and remove DICT_KEYS guard. We build the keys of a dict depth-first and we rely on the guards of each element in the dict to create the correct guards. This allows us to remove the rather buggy DICT_KEYS guard and make the guard lazy. The guards are not completely lazy yet, as we instantiate them in `_HashableTracker._eq_impl` but it should be possible to make them truly lazy. Also, adding new types to the supported types within keys should be less error prone. This is marginally less efficient when we graph break, but in turn we should graph break much less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`). cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 aakhundov kadeng [ghstack-poisoned]
…t) and avoid using DICT_KEYS guard" Make variables in dict lazy and remove DICT_KEYS guard. We build the keys of a dict depth-first and we rely on the guards of each element in the dict to create the correct guards. This allows us to remove the rather buggy DICT_KEYS guard and make the guard lazy. The guards are not completely lazy yet, as we instantiate them in `_HashableTracker._eq_impl` but it should be possible to make them truly lazy. Also, adding new types to the supported types within keys should be less error prone. This is marginally less efficient when we graph break, but in turn we should graph break much less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`). cc voznesenskym penguinwu EikanWang jgong5 Guobing-Chen XiaobingSuper zhuhaozhe blzheng wenzhe-nrv jiayisunx chenyang78 aakhundov kadeng [ghstack-poisoned]
pytorchmergebot
pushed a commit
that referenced
this pull request
Feb 2, 2024
Supersedes #118096 as a much cleaner and simpler solution. It is difficult to write a test for this one without exposing too much of the internals. You can see empirically that it works by running ``` TORCHDYNAMO_PRINT_GUARDS=1 TORCH_LOGS=+guards python test/test_optim.py -k test_can_load_older_state_dict_ASGD_cpu_float32 ``` Pull Request resolved: #118194 Approved by: https://github.com/jansel, https://github.com/peterbell10 ghstack dependencies: #117982, #118098, #117983, #117625
pytorchmergebot
pushed a commit
that referenced
this pull request
Feb 2, 2024
With this one, the only keys we are not tracing properly in the (non-skipped) test suite are `OutDtypeHigherOrderVariable()`, and a couple `UserDefinedObjectVariables` Pull Request resolved: #118003 Approved by: https://github.com/anijain2305, https://github.com/Skylion007, https://github.com/jansel ghstack dependencies: #117982, #118098, #117983, #117625, #118194
pytorchmergebot
pushed a commit
that referenced
this pull request
Feb 2, 2024
pytorchmergebot
pushed a commit
that referenced
this pull request
Feb 2, 2024
This is tested by `fullgraph=True` in the `test_getattr_dict` test. I can write a one-off test for both if that's needed. Pull Request resolved: #118199 Approved by: https://github.com/peterbell10, https://github.com/jansel, https://github.com/anijain2305 ghstack dependencies: #117982, #118098, #117983, #117625, #118194, #118003, #118208
pytorch-bot bot
pushed a commit
that referenced
this pull request
Feb 8, 2024
…d using DICT_KEYS guard (#117625) Make variables in dict lazy and remove DICT_KEYS guard. We build the keys of a dict depth-first and we rely on the guards of each element in the dict to create the correct guards. This allows us to remove the rather buggy DICT_KEYS guard and make the guard lazy. The guards are not completely lazy yet, as we instantiate them in `_HashableTracker._eq_impl` but it should be possible to make them truly lazy. Also, adding new types to the supported types within keys should be less error prone. This is marginally less efficient when we graph break, but in turn we should graph break much less. It also makes the dicts code easier to maintain (removes `is_hashable_python_var`). Pull Request resolved: #117625 Approved by: https://github.com/jansel, https://github.com/peterbell10, https://github.com/anijain2305 ghstack dependencies: #117982, #118098, #117983
pytorch-bot bot
pushed a commit
that referenced
this pull request
Feb 8, 2024
Supersedes #118096 as a much cleaner and simpler solution. It is difficult to write a test for this one without exposing too much of the internals. You can see empirically that it works by running ``` TORCHDYNAMO_PRINT_GUARDS=1 TORCH_LOGS=+guards python test/test_optim.py -k test_can_load_older_state_dict_ASGD_cpu_float32 ``` Pull Request resolved: #118194 Approved by: https://github.com/jansel, https://github.com/peterbell10 ghstack dependencies: #117982, #118098, #117983, #117625
pytorch-bot bot
pushed a commit
that referenced
this pull request
Feb 8, 2024
With this one, the only keys we are not tracing properly in the (non-skipped) test suite are `OutDtypeHigherOrderVariable()`, and a couple `UserDefinedObjectVariables` Pull Request resolved: #118003 Approved by: https://github.com/anijain2305, https://github.com/Skylion007, https://github.com/jansel ghstack dependencies: #117982, #118098, #117983, #117625, #118194
pytorch-bot bot
pushed a commit
that referenced
this pull request
Feb 8, 2024
This is tested by `fullgraph=True` in the `test_getattr_dict` test. I can write a one-off test for both if that's needed. Pull Request resolved: #118199 Approved by: https://github.com/peterbell10, https://github.com/jansel, https://github.com/anijain2305 ghstack dependencies: #117982, #118098, #117983, #117625, #118194, #118003, #118208
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
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):
Make variables in dict lazy and remove DICT_KEYS guard.
We build the keys of a dict depth-first and we rely on the guards of
each element in the dict to create the correct guards. This allows us to
remove the rather buggy DICT_KEYS guard and make the guard lazy.
The guards are not completely lazy yet, as we instantiate them in
_HashableTracker._eq_implbut it should be possible to make themtruly lazy.
Also, adding new types to the supported types within keys should be less
error prone.
This is marginally less efficient when we graph break, but in turn we
should graph break much less. It also makes the dicts code easier to maintain
(removes
is_hashable_python_var).cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng