-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
[poc] implement record_stream
when using CUDA streams during group offloading
#11081
base: main
Are you sure you want to change the base?
Conversation
The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update. |
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, I think we could consider adding. I did think about it during initial addition of group offloading, but like you reported, the time difference seemed very low, and I attributed it to randomness because it wasn't a ~20%-ish difference (as shown in gau-nerst's gist) and because I didn't spend time actually looking at the stream profiles.
Could you also run the benchmarks again with a warmup and the changes from #11094 and #11097?
Even though the I merged the PR branches into this PR branch and obtained the following numbers on the DGX: {"record_stream": false, "memory": "1.3514", "time": "32.065"}
{"record_stream": true, "memory": "1.3514", "time": "30.901"} On audace, I got: {"record_stream": false, "memory": "1.3514", "time": "430.398"}
{"record_stream": true, "memory": "1.3514", "time": "429.695"} |
for param in group_module.parameters(): | ||
param.data = param.data.to(self.onload_device, non_blocking=self.non_blocking) | ||
if self.record_stream: | ||
param.data.record_stream(current_stream) |
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.
current_stream should be self.stream here I think. We need to tell pytorch that the param.data and buffer.data here is owned by the non-default stream. Currently, we're telling it that it is owned by the default stream, which seems incorrect to me
Sorry for the back and forth but I think we will have to run the benchmark once more with the change 😅
Apart from this, everything else looks good. We can button up the docs and merge after @DN6 gives a look. Let's make sure to mention that this may use more memory in comparison to record_stream=False
in certain cases and link to the torch::Tensor::record_stream docs
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.
Oh nevermind, ignore my comment.
This method is most suitable for use cases where you are providing a function that created a tensor on a side stream, and want users to be able to make use of the tensor without having to think carefully about stream safety when making use of them.
We don't create anything on the non-default stream, so torch.cuda.current_stream is correct
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.
@a-r-r-o-w no problem. Better to be rigorous and double-check everything.
Just ran the benchmark after merging main
into this branch (on DGX on a single 80GB A100):
{"record_stream": false, "memory": "1.3514", "time": "32.792"}
{"record_stream": true, "memory": "1.3514", "time": "30.944"}
Feel free to run it yourself if you want.
Let's make sure to mention that this may use more memory in comparison to record_stream=False in certain cases and link to the torch::Tensor::record_stream docs
Absolutely. I will mention in the docstrings. Is there any other place you wanted me to mention it?
Co-authored-by: Aryan <[email protected]>
Will let @DN6 review and will propagate the Doc changes after that. |
@a-r-r-o-w @DN6 I have pulled in the latest improvements done to group offloading in this PR and resolved the conflicts. Have also run the benchmarks: {"record_stream": true, "memory": "1.3514", "time": "31.047"}
{"record_stream": false, "memory": "1.3514", "time": "32.213"} |
What does this PR do?
With group offloading, we shipped the possibility to overlap computation with communication (data transfers). This PR shows (thanks to the work of @gau-nernst) that when using CUDA streams, the speed can further be improved with
record_stream
.Code
Doesn't impact the quality.
Please note that this is just a PoC PR wherein I wanted to show the benefits of using record streams (it was easier with a PoC PR for me than opening a feature request). If this is good, I won't mind buttoning it up further myself for making it merge-ready or if the other maintainers directly commit to the PR branch for doing so. If the improvements are not good enough, I am happy to close the PR without asking anything.