Skip to content

Optimize MX4 padding to minimize need for tuning #3040

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

Closed
wants to merge 1 commit into from

Conversation

jwfromm
Copy link
Contributor

@jwfromm jwfromm commented Aug 26, 2024

Summary:
D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

Differential Revision: D61816830

Copy link

netlify bot commented Aug 26, 2024

Deploy Preview for pytorch-fbgemm-docs ready!

Name Link
🔨 Latest commit f4f7779
🔍 Latest deploy log https://app.netlify.com/sites/pytorch-fbgemm-docs/deploys/66cfbe77c77b7d000886ff37
😎 Deploy Preview https://deploy-preview-3040--pytorch-fbgemm-docs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

jwfromm added a commit to jwfromm/FBGEMM that referenced this pull request Aug 26, 2024
Summary:
X-link: facebookresearch/FBGEMM#137

Pull Request resolved: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

Differential Revision: D61816830
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

1 similar comment
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

jwfromm added a commit to jwfromm/FBGEMM that referenced this pull request Aug 26, 2024
Summary:
X-link: facebookresearch/FBGEMM#137

Pull Request resolved: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

Differential Revision: D61816830
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

jwfromm added a commit to jwfromm/FBGEMM that referenced this pull request Aug 26, 2024
Summary:
X-link: facebookresearch/FBGEMM#137

Pull Request resolved: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

Differential Revision: D61816830
jwfromm added a commit to jwfromm/FBGEMM that referenced this pull request Aug 26, 2024
Summary:
X-link: facebookresearch/FBGEMM#137

Pull Request resolved: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

After further experimentation, we can actually remove tuning entirely and just use a reasonably large `GROUP_LOAD`. This gives good performance across all shapes and removes any chance of overhead. Empirically, `GROUP_LOAD=64` seems to be the sweet spot.

Differential Revision: D61816830
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

1 similar comment
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

jwfromm added a commit to jwfromm/FBGEMM that referenced this pull request Aug 26, 2024
Summary:
X-link: facebookresearch/FBGEMM#137

Pull Request resolved: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

After further experimentation, we can actually remove tuning entirely and just use a reasonably large `GROUP_LOAD`. This gives good performance across all shapes and removes any chance of overhead. Empirically, `GROUP_LOAD=64` seems to be the sweet spot.

Differential Revision: D61816830
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

jwfromm added a commit to jwfromm/FBGEMM that referenced this pull request Aug 26, 2024
Summary:
X-link: facebookresearch/FBGEMM#137

Pull Request resolved: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

After further experimentation, we can actually remove tuning entirely and just use a reasonably large `GROUP_LOAD`. This gives good performance across all shapes and removes any chance of overhead. Empirically, `GROUP_LOAD=64` seems to be the sweet spot.

Differential Revision: D61816830
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

jwfromm added a commit to jwfromm/FBGEMM that referenced this pull request Aug 26, 2024
Summary:
X-link: facebookresearch/FBGEMM#137

Pull Request resolved: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

After further experimentation, we can actually remove tuning entirely and just use a reasonably large `GROUP_LOAD`. This gives good performance across all shapes and removes any chance of overhead. Empirically, `GROUP_LOAD=64` seems to be the sweet spot.

Differential Revision: D61816830
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

jwfromm added a commit to jwfromm/FBGEMM that referenced this pull request Aug 26, 2024
Summary:
X-link: facebookresearch/FBGEMM#137

Pull Request resolved: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

After further experimentation, we can actually remove tuning entirely and just use a reasonably large `GROUP_LOAD`. This gives good performance across all shapes and removes any chance of overhead. Empirically, `GROUP_LOAD=64` seems to be the sweet spot.

Differential Revision: D61816830
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

jwfromm added a commit to jwfromm/FBGEMM that referenced this pull request Aug 26, 2024
Summary:
X-link: facebookresearch/FBGEMM#137

Pull Request resolved: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

After further experimentation, we can actually remove tuning entirely and just use a reasonably large `GROUP_LOAD`. This gives good performance across all shapes and removes any chance of overhead. Empirically, `GROUP_LOAD=64` seems to be the sweet spot.

Differential Revision: D61816830
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

jwfromm added a commit to jwfromm/FBGEMM that referenced this pull request Aug 27, 2024
Summary:
X-link: facebookresearch/FBGEMM#137

Pull Request resolved: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

After further experimentation, we can actually remove tuning entirely and just use a reasonably large `GROUP_LOAD`. This gives good performance across all shapes and removes any chance of overhead. Empirically, `GROUP_LOAD=64` seems to be the sweet spot.

Differential Revision: D61816830
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

jwfromm added a commit to jwfromm/FBGEMM that referenced this pull request Aug 28, 2024
Summary:
X-link: facebookresearch/FBGEMM#137

Pull Request resolved: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

After further experimentation, we can actually remove tuning entirely and just use a reasonably large `GROUP_LOAD`. This gives good performance across all shapes and removes any chance of overhead. Empirically, `GROUP_LOAD=64` seems to be the sweet spot.

Differential Revision: D61816830
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

jwfromm added a commit to jwfromm/FBGEMM that referenced this pull request Aug 28, 2024
Summary:
X-link: facebookresearch/FBGEMM#137

Pull Request resolved: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

After further experimentation, we can actually remove tuning entirely and just use a reasonably large `GROUP_LOAD`. This gives good performance across all shapes and removes any chance of overhead. Empirically, `GROUP_LOAD=64` seems to be the sweet spot.

Differential Revision: D61816830
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

jwfromm added a commit to jwfromm/FBGEMM that referenced this pull request Aug 28, 2024
Summary:
X-link: facebookresearch/FBGEMM#137

Pull Request resolved: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

After further experimentation, we can actually remove tuning entirely and just use a reasonably large `GROUP_LOAD`. This gives good performance across all shapes and removes any chance of overhead. Empirically, `GROUP_LOAD=64` seems to be the sweet spot.

Differential Revision: D61816830
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

jwfromm added a commit to jwfromm/FBGEMM that referenced this pull request Aug 28, 2024
Summary:
X-link: facebookresearch/FBGEMM#137

Pull Request resolved: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

After further experimentation, we can actually remove tuning entirely and just use a reasonably large `GROUP_LOAD`. This gives good performance across all shapes and removes any chance of overhead. Empirically, `GROUP_LOAD=64` seems to be the sweet spot.

Differential Revision: D61816830
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

jwfromm added a commit to jwfromm/FBGEMM that referenced this pull request Aug 29, 2024
Summary:
X-link: facebookresearch/FBGEMM#137

Pull Request resolved: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

After further experimentation, we can actually remove tuning entirely and just use a reasonably large `GROUP_LOAD`. This gives good performance across all shapes and removes any chance of overhead. Empirically, `GROUP_LOAD=64` seems to be the sweet spot.

Differential Revision: D61816830
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

jwfromm added a commit to jwfromm/FBGEMM that referenced this pull request Aug 29, 2024
Summary:
X-link: facebookresearch/FBGEMM#137

Pull Request resolved: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

After further experimentation, we can actually remove tuning entirely and just use a reasonably large `GROUP_LOAD`. This gives good performance across all shapes and removes any chance of overhead. Empirically, `GROUP_LOAD=64` seems to be the sweet spot.

Differential Revision: D61816830
Summary:
X-link: facebookresearch/FBGEMM#137

Pull Request resolved: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

After further experimentation, we can actually remove tuning entirely and just use a reasonably large `GROUP_LOAD`. This gives good performance across all shapes and removes any chance of overhead. Empirically, `GROUP_LOAD=64` seems to be the sweet spot.

Differential Revision: D61816830
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D61816830

@facebook-github-bot
Copy link
Contributor

This pull request has been merged in c818b87.

q10 pushed a commit to q10/FBGEMM that referenced this pull request Apr 10, 2025
Summary:
Pull Request resolved: facebookresearch/FBGEMM#137

X-link: pytorch#3040

D61447274 introduced a very cool way of doing 2D indexing over input tensors during MX4 quantization, however, it is fairly reliant on tuning configurations to get good performance. It turns out the use case for MX4 has highly dynamic shapes, so we spend a huge amount of time tuning those shapes.

After deep meditation I realized there's a much simpler indexing scheme we can use, which is similar to the 1D accesses we used previously but adds shifts for padding.

With this approach we should get the best of both worlds; support for padding rows not divisible by group size and minimizing tuning while maintaining good performance.

After further experimentation, we can actually remove tuning entirely and just use a reasonably large `GROUP_LOAD`. This gives good performance across all shapes and removes any chance of overhead. Empirically, `GROUP_LOAD=64` seems to be the sweet spot.

Reviewed By: jianyuh

Differential Revision: D61816830

fbshipit-source-id: d35460ae39d374a699f57e43b2ee5b9675f00d69
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants