Micro-optimisations for matmul#64387
Closed
lezcano wants to merge 25 commits intogh/Lezcano/16/basefrom
Closed
Conversation
A number of these include: - Always prefer `DimVector` over `std::vector` when handling dimensions. - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. This also includes an optimisation by dispatching vector matrix prodcuts to `mv` rather than `mm`. Further optimisations could include dispatching to lower level functions when one of the inputs has shape `(n, 1)` or `(1, n)`. [ghstack-poisoned]
Contributor
🔗 Helpful links
💊 CI failures summary and remediationsAs of commit 7b18adf (more details on the Dr. CI page):
🕵️ 7 new failures recognized by patternsThe following CI failures do not appear to be due to upstream breakages:
|
lezcano
added a commit
that referenced
this pull request
Sep 1, 2021
A number of these include: - Always prefer `DimVector` over `std::vector` when handling dimensions. - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. This also includes an optimisation by dispatching vector matrix prodcuts to `mv` rather than `mm`. Further optimisations could include dispatching to lower level functions when one of the inputs has shape `(n, 1)` or `(1, n)`. ghstack-source-id: f654d1d Pull Request resolved: #64387
A number of these include: - Always prefer `DimVector` over `std::vector` when handling dimensions. - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. This also includes an optimisation by dispatching vector matrix prodcuts to `mv` rather than `mm`. Further optimisations could include dispatching to lower level functions when one of the inputs has shape `(n, 1)` or `(1, n)`. cc @jianyuh @nikitaved @pearu @mruberry @heitorschueroff @walterddr @IvanYashchuk @xwang233 @lezcano [ghstack-poisoned]
A number of these include: - Always prefer `DimVector` over `std::vector` when handling dimensions. - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. This also includes an optimisation by dispatching vector matrix prodcuts to `mv` rather than `mm`. Further optimisations could include dispatching to lower level functions when one of the inputs has shape `(n, 1)` or `(1, n)`. cc @jianyuh @nikitaved @pearu @mruberry @heitorschueroff @walterddr @IvanYashchuk @xwang233 @lezcano [ghstack-poisoned]
lezcano
added a commit
that referenced
this pull request
Sep 2, 2021
A number of these include: - Always prefer `DimVector` over `std::vector` when handling dimensions. - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. This also includes an optimisation by dispatching vector matrix prodcuts to `mv` rather than `mm`. Further optimisations could include dispatching to lower level functions when one of the inputs has shape `(n, 1)` or `(1, n)`. ghstack-source-id: ef79746 Pull Request resolved: #64387
ngimel
reviewed
Sep 2, 2021
A number of these include: - Always prefer `DimVector` over `std::vector` when handling dimensions. - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. This also includes an optimisation by dispatching vector matrix prodcuts to `mv` rather than `mm`. Further optimisations could include dispatching to lower level functions when one of the inputs has shape `(n, 1)` or `(1, n)`. cc @VitalyFedyunin ngimel heitorschueroff jianyuh nikitaved pearu mruberry walterddr @IvanYashchuk xwang233 @lezcano [ghstack-poisoned]
lezcano
added a commit
that referenced
this pull request
Sep 7, 2021
A number of these include: - Always prefer `DimVector` over `std::vector` when handling dimensions. - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. This also includes an optimisation by dispatching vector matrix prodcuts to `mv` rather than `mm`. Further optimisations could include dispatching to lower level functions when one of the inputs has shape `(n, 1)` or `(1, n)`. ghstack-source-id: 1e996bb Pull Request resolved: #64387
Collaborator
Author
|
The following script: from torch.utils.benchmark import Timer
import timeit
timer = Timer("torch::matmul(m1, m2);", setup="at::Tensor m1=torch::zeros({1,1,1});at::Tensor
m2=torch::zeros({1,1,1});", language="c++", timer=timeit.default_timer)
stats=timer.collect_callgrind(number=30, repeats=3)
print(stats[1].as_standardized().stats(inclusive=False))Throws an instruction count of Using shapes |
A number of these include: - Always prefer `DimVector` over `std::vector` when handling dimensions. - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. This also includes an optimisation by dispatching vector matrix prodcuts to `mv` rather than `mm`. Further optimisations could include dispatching to lower level functions when one of the inputs has shape `(n, 1)` or `(1, n)`. cc @VitalyFedyunin ngimel heitorschueroff jianyuh nikitaved pearu mruberry walterddr @IvanYashchuk xwang233 @lezcano [ghstack-poisoned]
Collaborator
Author
|
A more thorough instruction bench.
Note in particular the 50% instructions in the case when the rhs is a batch of matrices and the lhs is a vector. The reduction in the case when we use the out version is likely higher, but I did not bench that branch as it's not used nearly as much as the main branch. This PR implements a number of general principles to try to save on unnecessary computations:
This is ready for review @ngimel |
A number of these include: - Always prefer `DimVector` over `std::vector` when handling dimensions. - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. This also includes an optimisation by dispatching vector matrix prodcuts to `mv` rather than `mm`. Further optimisations could include dispatching to lower level functions when one of the inputs has shape `(n, 1)` or `(1, n)`. cc @VitalyFedyunin ngimel heitorschueroff jianyuh nikitaved pearu mruberry walterddr @IvanYashchuk xwang233 @lezcano [ghstack-poisoned]
lezcano
added a commit
that referenced
this pull request
Sep 8, 2021
A number of these include: - Always prefer `DimVector` over `std::vector` when handling dimensions. - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. This also includes an optimisation by dispatching vector matrix prodcuts to `mv` rather than `mm`. Further optimisations could include dispatching to lower level functions when one of the inputs has shape `(n, 1)` or `(1, n)`. ghstack-source-id: 4aa9e4a Pull Request resolved: #64387
A number of these include: - Always prefer `DimVector` over `std::vector` when handling dimensions. - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. This also includes an optimisation by dispatching vector matrix prodcuts to `mv` rather than `mm`. Further optimisations could include dispatching to lower level functions when one of the inputs has shape `(n, 1)` or `(1, n)`. cc @VitalyFedyunin ngimel heitorschueroff jianyuh nikitaved pearu mruberry walterddr @IvanYashchuk xwang233 @lezcano [ghstack-poisoned]
lezcano
added a commit
that referenced
this pull request
Sep 9, 2021
A number of these include: - Always prefer `DimVector` over `std::vector` when handling dimensions. - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. This also includes an optimisation by dispatching vector matrix prodcuts to `mv` rather than `mm`. Further optimisations could include dispatching to lower level functions when one of the inputs has shape `(n, 1)` or `(1, n)`. ghstack-source-id: ec7134d Pull Request resolved: #64387
ngimel
reviewed
Sep 14, 2021
Collaborator
ngimel
left a comment
There was a problem hiding this comment.
Sorry for delay with review, this looks great, I have small questions about testing.
| const Tensor output = at::_unsafe_view(at::mm_out(*out_opt, t1, tensor2), output_size); | ||
| return out_opt->set_(output); | ||
| } else { | ||
| const Tensor output = at::_unsafe_view(at::native::mv_out(t1, tensor2, *out_opt), output_size); |
Collaborator
There was a problem hiding this comment.
ugh, native::mv_out and at::mm_out couple lines above is pretty confusing (not to mention their different order of out argument)
Collaborator
Author
There was a problem hiding this comment.
I know... There is no native::mm_out so I could not call it directly...
test/test_linalg.py
Outdated
| assertEqual(ans, expected) | ||
|
|
||
| out = torch.zeros(*shape, dtype=torch.int64).to(x.device) | ||
| out = torch.empty((0,), dtype=x.dtype, device=x.device) |
Collaborator
There was a problem hiding this comment.
To make tests more robust, you probably want to allocate out of the correct shape filled with nans here, but you got rid of the shape, so I don't know how feasible it is.
Collaborator
Author
There was a problem hiding this comment.
Luckily we compute the non-out version just before, so we have the shapes there :)
A number of these include: - Always prefer `DimVector` over `std::vector` when handling dimensions. - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. This also includes an optimisation by dispatching vector matrix prodcuts to `mv` rather than `mm`. Further optimisations could include dispatching to lower level functions when one of the inputs has shape `(n, 1)` or `(1, n)`. cc @VitalyFedyunin ngimel heitorschueroff jianyuh nikitaved pearu mruberry walterddr @IvanYashchuk xwang233 @lezcano [ghstack-poisoned]
swolchok
added a commit
that referenced
this pull request
Feb 4, 2022
Here's a small PR that only fixes the extra heap allocations for shapes. Hopefully won't get stuck like #64387. Differential Revision: [D33962610](https://our.internmc.facebook.com/intern/diff/D33962610/) [ghstack-poisoned]
swolchok
added a commit
that referenced
this pull request
Feb 4, 2022
Pull Request resolved: #72230 Here's a small PR that only fixes the extra heap allocations for shapes. Hopefully won't get stuck like #64387. ghstack-source-id: 148446641 Differential Revision: [D33962610](https://our.internmc.facebook.com/intern/diff/D33962610/)
swolchok
added a commit
that referenced
this pull request
Feb 7, 2022
Here's a small PR that only fixes the extra heap allocations for shapes. Hopefully won't get stuck like #64387. Differential Revision: [D33962610](https://our.internmc.facebook.com/intern/diff/D33962610/) [ghstack-poisoned]
swolchok
added a commit
that referenced
this pull request
Feb 7, 2022
Here's a small PR that only fixes the extra heap allocations for shapes. Hopefully won't get stuck like #64387. Differential Revision: [D33962610](https://our.internmc.facebook.com/intern/diff/D33962610/) [ghstack-poisoned]
swolchok
added a commit
that referenced
this pull request
Feb 7, 2022
Pull Request resolved: #72230 Here's a small PR that only fixes the extra heap allocations for shapes. Hopefully won't get stuck like #64387. ghstack-source-id: 148556529 Differential Revision: [D33962610](https://our.internmc.facebook.com/intern/diff/D33962610/)
Contributor
|
@lezcano what's the status on this |
Collaborator
Author
|
I have to have another look at this one and split it into several smaller PRs to find where's the problem. I'll do that soon™ |
swolchok
added a commit
that referenced
this pull request
Feb 14, 2022
Pull Request resolved: #72230 Here's a small PR that only fixes the extra heap allocations for shapes. Hopefully won't get stuck like #64387. ghstack-source-id: 149069527 Differential Revision: [D33962610](https://our.internmc.facebook.com/intern/diff/D33962610/)
swolchok
added a commit
that referenced
this pull request
Feb 14, 2022
Here's a small PR that only fixes the extra heap allocations for shapes. Hopefully won't get stuck like #64387. Differential Revision: [D33962610](https://our.internmc.facebook.com/intern/diff/D33962610/) [ghstack-poisoned]
swolchok
added a commit
that referenced
this pull request
Feb 14, 2022
Here's a small PR that only fixes the extra heap allocations for shapes. Hopefully won't get stuck like #64387. Differential Revision: [D33962610](https://our.internmc.facebook.com/intern/diff/D33962610/) [ghstack-poisoned]
facebook-github-bot
pushed a commit
that referenced
this pull request
Feb 15, 2022
Summary: Pull Request resolved: #72230 Here's a small PR that only fixes the extra heap allocations for shapes. Hopefully won't get stuck like #64387. ghstack-source-id: 149069527 Test Plan: CI Reviewed By: ngimel Differential Revision: D33962610 fbshipit-source-id: 51e200f5237bdf225bfb2445e1e36bacd0e65e92
pytorchmergebot
pushed a commit
that referenced
this pull request
Feb 15, 2022
Summary: Pull Request resolved: #72230 Here's a small PR that only fixes the extra heap allocations for shapes. Hopefully won't get stuck like #64387. ghstack-source-id: 149069527 Test Plan: CI Reviewed By: ngimel Differential Revision: D33962610 fbshipit-source-id: 51e200f5237bdf225bfb2445e1e36bacd0e65e92 (cherry picked from commit 027537f)
Collaborator
Author
|
@pytorchbot ciflow rerun |
|
This command didn't do anything. |
Collaborator
Author
|
@pytorchbot ciflow rerun -l ciflow/all |
|
This command didn't do anything. |
lezcano
added a commit
that referenced
this pull request
Apr 4, 2022
This PR implements the bulk of #64387 Part of the optimisations were already merged in #72230 A number of these optimisations include: - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. - Call `reshape` rather than `expect_contiguous` + `view` On top of these, it fixes a correctness issue of `matmul_out`, where the out parameter was not resized correctly when passed to the backends. This involves removing the use of `set_` from the calling code, as requested by @ezyang, and it incurs on most of the complexity of the code that this PR adds. [ghstack-poisoned]
Collaborator
Author
|
This PR has been split into a number of PRs to try to isolate the CI errors. See #75193 |
lezcano
added a commit
that referenced
this pull request
Apr 4, 2022
…ic boogaloo" This PR implements the bulk of #64387 Part of the optimisations were already merged in #72230 A number of these optimisations include: - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. - Call `reshape` rather than `expect_contiguous` + `view` On top of these, it fixes a correctness issue of `matmul_out`, where the out parameter was not resized correctly when passed to the backends. This involves removing the use of `set_` from the calling code, as requested by ezyang, and it incurs on most of the complexity of the code that this PR adds. [ghstack-poisoned]
lezcano
added a commit
that referenced
this pull request
Apr 4, 2022
This PR implements the bulk of #64387 Part of the optimisations were already merged in #72230 A number of these optimisations include: - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. - Call `reshape` rather than `expect_contiguous` + `view` On top of these, it fixes a correctness issue of `matmul_out`, where the out parameter was not resized correctly when passed to the backends. This involves removing the use of `set_` from the calling code, as requested by ezyang, and it incurs on most of the complexity of the code that this PR adds. [ghstack-poisoned]
lezcano
added a commit
that referenced
this pull request
Apr 4, 2022
…ic boogaloo" This PR implements the bulk of #64387 Part of the optimisations were already merged in #72230 A number of these optimisations include: - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. - Call `reshape` rather than `expect_contiguous` + `view` On top of these, it fixes a correctness issue of `matmul_out`, where the out parameter was not resized correctly when passed to the backends. This involves removing the use of `set_` from the calling code, as requested by ezyang, and it incurs on most of the complexity of the code that this PR adds. [ghstack-poisoned]
lezcano
added a commit
that referenced
this pull request
Apr 4, 2022
This PR implements the bulk of #64387 Part of the optimisations were already merged in #72230 A number of these optimisations include: - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. - Call `reshape` rather than `expect_contiguous` + `view` On top of these, it fixes a correctness issue of `matmul_out`, where the out parameter was not resized correctly when passed to the backends. This involves removing the use of `set_` from the calling code, as requested by ezyang, and it incurs on most of the complexity of the code that this PR adds. [ghstack-poisoned]
lezcano
added a commit
that referenced
this pull request
Apr 4, 2022
This PR implements the bulk of #64387 Part of the optimisations were already merged in #72230 A number of these optimisations include: - Make the code `const` correct. - Create `DimVector`'s more efficiently (e.g. prefer `append` over `insert`). - Access sizes of the tensors via `sizes().front()` / `sizes().back()` / `sizes().end()[-2]` - Do not create intermediary tensors / vectors when it can be avoided. - Call `reshape` rather than `expect_contiguous` + `view` On top of these, it fixes a correctness issue of `matmul_out`, where the out parameter was not resized correctly when passed to the backends. This involves removing the use of `set_` from the calling code, as requested by ezyang, and it incurs on most of the complexity of the code that this PR adds. ghstack-source-id: 97a8759 Pull Request resolved: #75197
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
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:
A number of these include:
DimVectoroverstd::vectorwhen handling dimensions.constcorrect.DimVector's more efficiently (e.g. preferappendoverinsert).sizes().front()/sizes().back()/
sizes().end()[-2]mvrather thanmmin the case(n,) x (n, m).reshaperather thanexpect_contiguous+viewOn top of this, while fixing the CI and after further discussions, the following features were added.
mv,matmul,__rmatmul___out.set_. (requested by @ezyang )matmul_out.Looking into the future, further optimisations could include dispatching to lower level functions
when one of the inputs has shape
(n, 1)or(1, n).Fixes #67767
cc @VitalyFedyunin @ngimel @jianyuh @nikitaved @pearu @mruberry @walterddr @IvanYashchuk @xwang233 @lezcano @heitorschueroff