Improve performance of prefill mode FP8 Grouped Gemm #3522
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
|
This pull request was exported from Phabricator. Differential Revision: D67531231 |
✅ Deploy Preview for pytorch-fbgemm-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
jwfromm
added a commit
to jwfromm/FBGEMM
that referenced
this pull request
Dec 20, 2024
Summary: X-link: facebookresearch/FBGEMM#603 I previously assumed that using hipmemcpy would be more efficient than launching many kernels that directly set gpu memory. This assumption is apparently (and very surprisingly) untrue. It seems the the multi-kernel-launch approach reduces overhead considerably, giving a 10% speedup. Differential Revision: D67531231
jwfromm
force-pushed
the
export-D67531231
branch
from
71fed6a to
0322843
Compare
|
This pull request was exported from Phabricator. Differential Revision: D67531231 |
jwfromm
pushed a commit
to jwfromm/FBGEMM
that referenced
this pull request
Dec 22, 2024
Summary: Pull Request resolved: pytorch#3522 X-link: facebookresearch/FBGEMM#603 I previously assumed that using hipmemcpy would be more efficient than launching many kernels that directly set gpu memory. This assumption is apparently (and very surprisingly) untrue. It seems the the multi-kernel-launch approach reduces overhead considerably, giving a 10% speedup. Differential Revision: D67531231
Summary: X-link: facebookresearch/FBGEMM#603 It turns out that setting up the grouped gemm kernel arguments can be a significant overhead. This diff more carefully checks the number of groups to dispatch to either a hipmemcpy based approach, which works well when there are 16 more groups, or a series of kernels that directly sets the gpu memory for each group. For smaller number of groups, this approach provides a pretty substantial speedup. Reviewed By: jianyuh Differential Revision: D67531231
jwfromm
force-pushed
the
export-D67531231
branch
from
0322843 to
47b6396
Compare
|
This pull request was exported from Phabricator. Differential Revision: D67531231 |
|
This pull request has been merged in 8a1ca16. |
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.
Summary: I previously assumed that using hipmemcpy would be more efficient than launching many kernels that directly set gpu memory. This assumption is apparently (and very surprisingly) untrue. It seems the the multi-kernel-launch approach reduces overhead considerably, giving a 10% speedup.
Differential Revision: D67531231