-
Notifications
You must be signed in to change notification settings - Fork 25.7k
Opportunistically use ncclCommSplit when creating new NCCL groups
#112889
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/112889
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit d90c747 with merge base 4b7f9fa ( This comment was automatically generated by Dr. CI and updates every 15 minutes. |
|
|
0ea2d4b to
0ceb454
Compare
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.
Synchronized between? Can the comment specify 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.
whoops, we don't even need this anymore. removing.
|
I wonder if we would eventually need to expose the "color" via one/some of the
|
c815b98 to
b0adac9
Compare
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.
LGTM.
I just have 3 minor comments.
|
I resolved the three last comments. I believe we are good to go. Thanks! |
7fcf3cd to
be8a570
Compare
Currently `ncclCommInitRankConfig` is always used when creating new communicator groups. This is wasteful as it creates non-shared pairs of endpoint queues as well as costs time to re-establish communication. This change is transparent and opportunistic; when `dist.new_group` is called and the new group includes all ranks, it will use the existing, healthy world process group to select the right ranks to include in the process group.
be8a570 to
d90c747
Compare
|
@pytorchmergebot 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 |
|
@pytorchbot revert -m 'Sorry for reverting you change, but it is failing ROCm distributed jobs in trunk https://hud.pytorch.org/pytorch/pytorch/commit/4d07428edee863e7f5920f0672957a9711a9f0b5' -c nosignal The error is |
|
@pytorchbot successfully started a revert job. Check the current status here. |
|
@chipturner your PR has been successfully reverted. |
…groups (#112889)" This reverts commit 64a5372. Reverted #112889 on behalf of https://github.com/huydhn due to Sorry for reverting you change, but it is failing ROCm distributed jobs in trunk https://hud.pytorch.org/pytorch/pytorch/commit/4d07428edee863e7f5920f0672957a9711a9f0b5 ([comment](#112889 (comment)))
Reverting PR 112889 failedReason: HTTP Error 422: Unprocessable Entity Details for Dev Infra teamRaised by workflow job |
…w NCCL groups (pytorch#112889) Currently `ncclCommInitRankConfig` is always used when creating new communicator groups. This is wasteful as it creates non-shared pairs of endpoint queues as well as costs time to re-establish communication. This change is transparent and opportunistic; when `dist.new_group` is called, it will use the existing, healthy world process group to select the right ranks to include in the process group. Original PR: pytorch#112889 Reverted due to ROCm incompatibility
…NCCL groups) (#114385) - [c10d] (retry) Opportunistically use `ncclCommSplit` when creating new NCCL groups (#112889) - Guard use of `split_from` with a `hasattr` check for cases when NCCL (or RCCL) lacks `ncclCommSplit` Fixes cause of revert of original PR Pull Request resolved: #114385 Approved by: https://github.com/huydhn
…114423) When reopening a reverted PR, `422: Unprocessable Entity` is returned when the head branch has been deleted, for example #112889 (comment) ``` { "message": "Validation Failed", "errors": [ { "resource": "PullRequest", "code": "custom", "field": "state", "message": "state cannot be changed. The commsplit branch has been deleted." } ], "documentation_url": "https://docs.github.com/rest/pulls/pulls#update-a-pull-request" } ``` The revert still happens though, only reopening PR fails, which is ok to ignore in this case I think instead of going the complicated route of trying to restore the deleted branch by merge bot. Pull Request resolved: #114423 Approved by: https://github.com/malfet, https://github.com/kit1980
|
@chipturner Can you provide a pytorch test case to quantify the performance improvement brought by comm_split? |
Currently
ncclCommInitRankConfigis always used when creating newcommunicator groups. This is wasteful as it creates non-shared pairs
of endpoint queues as well as costs time to re-establish
communication.
This change is transparent and opportunistic; when
dist.new_groupiscalled, it will use the existing, healthy world process group to
select the right ranks to include in the process group.