Making ops c10-full: optional lists#49088
Closed
smessmer wants to merge 20 commits intogh/smessmer/281/basefrom
Closed
Making ops c10-full: optional lists#49088smessmer wants to merge 20 commits intogh/smessmer/281/basefrom
smessmer wants to merge 20 commits intogh/smessmer/281/basefrom
Conversation
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
This was referenced Dec 9, 2020
smessmer
added a commit
that referenced
this pull request
Dec 9, 2020
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) ghstack-source-id: 118184335 Pull Request resolved: #49088
24 tasks
💊 CI failures summary and remediationsAs of commit 9eef798 (more details on the Dr. CI page): 💚 💚 Looks good so far! There are no failures yet. 💚 💚 This comment was automatically generated by Dr. CI (expand for details).Follow this link to opt-out of these comments for your Pull Requests.Please report bugs/suggestions to the (internal) Dr. CI Users group. This comment has been revised 83 times. |
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
This was referenced Dec 10, 2020
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
ezyang
approved these changes
Dec 10, 2020
Contributor
ezyang
left a comment
There was a problem hiding this comment.
Vector allocation here is still giving me hives. It looks like the operators affected here are only cold names operators though. @swolchok I cc'ed you specifically about the vector allocation in aten/src/ATen/core/boxing/impl/make_boxed_from_unboxed_functor.h
Contributor
I don’t see a new allocation in that file, just a generalization of existing special cases. What am I missing? |
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
Contributor
I don't think this PR makes it worse. But it touches code that is not so great. |
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
bhosmer
approved these changes
Dec 11, 2020
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
This was referenced Dec 11, 2020
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. Differential Revision: [D25423901](https://our.internmc.facebook.com/intern/diff/D25423901/) [ghstack-poisoned]
Contributor
|
This pull request has been merged in ec8e9d3. |
hwangdeyu
pushed a commit
to hwangdeyu/pytorch
that referenced
this pull request
Jan 6, 2021
Summary: Pull Request resolved: pytorch#49088 We had special case logic to support `int[]?` and `double[]?` but nothing for `DimnameList[]?`. This PR generalizes the logic to support optional lists so it should now work with all types. It also enables c10-fullness for ops that were blocked by this. Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied. We should probably consider alternatives in the future like for example using `torch::List` instead of `ArrayRef`, that could work without copying the list. ghstack-source-id: 118660071 Test Plan: waitforsandcastle Reviewed By: ezyang Differential Revision: D25423901 fbshipit-source-id: dec58dc29f3bb4cbd89e2b95c42da204a9da2e0a
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
5 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:
use_c10_dispatcher: fulllines #49259 Removeuse_c10_dispatcher: fulllinesWe had special case logic to support
int[]?anddouble[]?but nothing forDimnameList[]?.This PR generalizes the logic to support optional lists so it should now work with all types.
It also enables c10-fullness for ops that were blocked by this.
Note that using these arguments in a signature was always and still is expensive because the whole list needs to be copied.
We should probably consider alternatives in the future like for example using
torch::Listinstead ofArrayRef, that could work without copying the list.Differential Revision: D25423901