[FSDP][Perf] Do not call pad in no-padding case
#88769
Closed
Conversation
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
[ghstack-poisoned]
awgu
requested review from
mrshenli,
zhaojuanmao,
pritamdamania87,
rohan-varma,
H-Huang and
kwen2501
as code owners
pytorch-bot
bot
added
the
release notes: distributed (fsdp)
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/88769
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit 1761e6a: This comment was automatically generated by Dr. CI and updates every 15 minutes. |
awgu
added a commit
that referenced
this pull request
Nov 9, 2022
ghstack-source-id: da8c8378455e723a42b6d4b23145b1536331eee9 Pull Request resolved: #88769
zhaojuanmao
approved these changes
Nov 10, 2022
- Calling `F.pad()` issues a pad kernel from the CPU even if there is no padding needed, which can incur some non-negligible overhead. This PR removes that unnecessary call for the no-padding case. - This PR also does not zero the newly-allocated sharded gradient tensor before the reduce-scatter if `use_orig_params=True` because there is no need. The reduce-scatter will fill the tensor anyway, and we do not care about the values in the padding. For `use_orig_params=False`, the padding is exposed to the user, so we preserve the existing semantics of zeroing it. I left a to-do to follow-up since we may optimize that. [ghstack-poisoned]
awgu
added a commit
that referenced
this pull request
Nov 10, 2022
ghstack-source-id: 4a1cca1ef167964173892bc16cf54a5716c0191e Pull Request resolved: #88769
|
@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 |
- Calling `F.pad()` issues a pad kernel from the CPU even if there is no padding needed, which can incur some non-negligible overhead. This PR removes that unnecessary call for the no-padding case. - This PR also does not zero the newly-allocated sharded gradient tensor before the reduce-scatter if `use_orig_params=True` because there is no need. The reduce-scatter will fill the tensor anyway, and we do not care about the values in the padding. For `use_orig_params=False`, the padding is exposed to the user, so we preserve the existing semantics of zeroing it. I left a to-do to follow-up since we may optimize that. [ghstack-poisoned]
This was referenced Nov 10, 2022
Merge failedReason: New commits were pushed while merging. Please rerun the merge command. Details for Dev Infra teamRaised by workflow job |
awgu
added a commit
to awgu/pytorch
that referenced
this pull request
Nov 10, 2022
ghstack-source-id: da8c8378455e723a42b6d4b23145b1536331eee9 Pull Request resolved: pytorch#88769
- Calling `F.pad()` issues a pad kernel from the CPU even if there is no padding needed, which can incur some non-negligible overhead. This PR removes that unnecessary call for the no-padding case. - This PR also does not zero the newly-allocated sharded gradient tensor before the reduce-scatter if `use_orig_params=True` because there is no need. The reduce-scatter will fill the tensor anyway, and we do not care about the values in the padding. For `use_orig_params=False`, the padding is exposed to the user, so we preserve the existing semantics of zeroing it. I left a to-do to follow-up since we may optimize that. [ghstack-poisoned]
awgu
added a commit
to awgu/pytorch
that referenced
this pull request
Nov 10, 2022
ghstack-source-id: 0f8c479efccb74b0f1f0e43e940bc85de774e0a5 Pull Request resolved: pytorch#88769
|
@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 |
|
This allocation happened previously in the post-backward stream, which induced cross-stream memory fragmentation. (Only the sharded gradient needs to be allocated in the post-backward stream, not the unsharded gradient.) For T5-11B on 2 nodes and batch size 6, eliminating the unnecessary |
kulinseth
pushed a commit
to kulinseth/pytorch
that referenced
this pull request
Dec 10, 2022
- Calling `F.pad()` issues a pad kernel from the CPU even if there is no padding needed, which can incur some non-negligible overhead. This PR removes that unnecessary call for the no-padding case. - This PR also does not zero the newly-allocated sharded gradient tensor before the reduce-scatter if `use_orig_params=True` because there is no need. The reduce-scatter will fill the tensor anyway, and we do not care about the values in the padding. For `use_orig_params=False`, the padding is exposed to the user, so we preserve the existing semantics of zeroing it. I left a to-do to follow-up since we may optimize that. Pull Request resolved: pytorch#88769 Approved by: https://github.com/zhaojuanmao
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:
ModuleWrapPolicy#88453 [Dynamo][FSDP] Migrate toModuleWrapPolicyModuleWrapPolicyfor simplicity #88450 [FSDP] IntroduceModuleWrapPolicyfor simplicitypadin no-padding case #88769 [FSDP][Perf] Do not callpadin no-padding caseF.pad()issues a pad kernel from the CPU even if there is no padding needed, which can incur some non-negligible overhead. This PR removes that unnecessary call for the no-padding case.use_orig_params=Truebecause there is no need. The reduce-scatter will fill the tensor anyway, and we do not care about the values in the padding. Foruse_orig_params=False, the padding is exposed to the user, so we preserve the existing semantics of zeroing it. I left a to-do to follow-up since we may optimize that.