-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Fix torch.distributed._functional_collectives.AsyncCollectiveTensor for aten.to. #134661
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
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/134661
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit c4425cc with merge base b336d72 ( This comment was automatically generated by Dr. CI and updates every 15 minutes. |
@bdhirsh can you help review? |
@@ -432,6 +432,9 @@ def reduce_scatter_tensor_coalesced( | |||
# Today, this maps 1:1 with "aten ops that are views". | |||
def _is_view_op(tgt): | |||
assert isinstance(tgt, torch._ops.OpOverload) | |||
# Special case for `aten.to`. See issue: https://github.com/pytorch/pytorch/issues/133421 | |||
if "to" in tgt.__name__.split('.'): | |||
return False |
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.
hmm this feels like a bit of bandaid fix (although I agree it solves the aten.to
problem).
The issue is that we have several composite operations that are "maybe-aliasing", and therefore can lie about their schemas. aten.to.device
is an example: it may-or-may-not alias input, depending on whether the device matches the input tensor, but its schema reports as always aliasing.
Ordinarily, these ops will always decompose before we get to torch_dispatch. But under inference_mode, these ops can show up directly in torch_dispatch.
The way we've generally dealt with this for other subclasses is to force them to decompose these composite ops, by adding this code:
r = func.decompose(*args, **kwargs)
# this will attempt to run the eager-mode decomposition if one exists, and return NotImplemented otherwise
if r is not NotImplemented:
return r
Although cc @weifengpy, I'm curious what you think, since this could have an impact on eager performance (we'd probably have to measure it)
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.
however, given that AsyncCollectiveTensor doesn't really do very much other than branch on view ops... another strategy that is more general than this PR but might be less risky for perf would just be to have AsyncCollectiveTensor
assume that all of these composite ops are not views (worst case, it does an early sync when it doesn't have to, but most view ops are not composite anyway).
You can do it like this:
# don't apply the view optimization to any `CompositeImplicitAutograd` ops
if torch._C._dispatch_has_kernel_for_dispatch_key(func.name(), DispatchKey.CompositeImplicitAutograd):
return False
fyi @weifengpy @wanchaol
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.
sry for the late reply, I've fixed it in a more general way according to your suggestion. @bdhirsh
944c172
to
85ddb7a
Compare
354568d
to
bf91cd1
Compare
Looks like this PR hasn't been updated in a while so we're going to go ahead and mark this as |
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 fix!
@pytorchbot merge |
Pull workflow has not been scheduled for the PR yet. It could be because author doesn't have permissions to run those or skip-checks keywords were added to PR/commits, aborting merge. Please get/give approval for the workflows and/or remove skip ci decorators before next merge attempt. If you think this is a mistake, please contact PyTorch Dev Infra. |
@pytorchbot merge |
Merge startedYour change will be merged once all checks pass (ETA 0-4 Hours). Learn more about merging in the wiki. Questions? Feedback? Please reach out to the PyTorch DevX Team |
Merge failedReason: 2 mandatory check(s) failed. The first few are: Dig deeper by viewing the failures on hud |
@pytorchbot rebase |
@pytorchbot help |
❌ 🤖 pytorchbot command failed:
Try |
@pytorchbot --help |
PyTorchBot Help
Merge
Revert
Rebase
Label
Dr CI
cherry-pick
Closeusage: @pytorchbot close Close a PR [Can be used on issues] |
@pytorchbot merge -r |
@pytorchbot started a rebase job onto refs/remotes/origin/viable/strict. Check the current status here |
Successfully rebased |
bf91cd1
to
c4425cc
Compare
@pytorchbot started a rebase job onto refs/remotes/origin/viable/strict. Check the current status here |
The merge job was canceled or timed out. This most often happen if two merge requests were issued for the same PR, or if merge job was waiting for more than 6 hours for tests to finish. In later case, please do not hesitate to reissue the merge command |
@pytorchbot merge |
Merge startedYour change will be merged once all checks pass (ETA 0-4 Hours). Learn more about merging in the wiki. Questions? Feedback? Please reach out to the PyTorch DevX Team |
…2688) We never added a proper test for the fix from #134661 Pull Request resolved: #152688 Approved by: https://github.com/kwen2501 ghstack dependencies: #152195
Fixes #133421
cc @XilunWu @H-Huang @awgu @kwen2501 @wanchaol @fegin @fduwjj @wz337 @wconstab @d4l3k @c-p-i-o