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.
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
GH-33923: [Docs] Tensor canonical extension type specification #33925
GH-33923: [Docs] Tensor canonical extension type specification #33925
Changes from 6 commits
af571cb
8231150
884d871
83edd70
16ef6f1
4f4ccce
92fd7c6
7873676
a4219e3
37e83db
5c92ff0
cb5e2dd
b562b8d
c44101b
24e7c28
333ae67
4086dfb
bd2a515
bc07d7a
68c6244
3e2bb25
a49f14f
89d8042
4ff7a65
1daf820
70059d9
6f44296
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Can we not store
stride
instead? https://pytorch.org/docs/stable/generated/torch.Tensor.stride.html#torch.Tensor.strideThere 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.
In the Zulip discussion we are leaning towards canonical type always storing row-major and letting applications store strides in metadata. Any arguments for or against from you or your users would be most welcome at this point!
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.
So you mean removing
is_row_major
as a parameter? I guess the issue boils down to how fast you want the loading/saving? In torch terminology, making a tensor contiguous (I'm guessing is the same as row major) makes a copy because the underlying memory representation changes. The same would apply to loading.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.
Yes. We would just use the physical layout of the source and not change memory layout when going in and out of the extension. We would provide an option to store the layout as metadata.
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.
My understanding is that contiguous tensors in torch are indeed always row-major, but so that also means that if you have such a contiguous tensor, you don't need any copy to put this in the proposed extension TensorArray (or you can get it out without a copy).
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.
I don't know if that helps the discussion:
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.
Yes, but both of those use row-major / C-contiguous memory layout. What you change is the order of the dimensions (C-H-W or H-W-C), and to do that while keeping row-major layout, changing between channels first/last layout requires actually shuffling the data in memory (and thus requires a copy). But either "physical order" is row-major and thus can be stored in the proposed FixedShapeTensor array without copy.
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.
For your example,
x
andy
indeed have a different layout of the values in memory, while seemingly representing the same tensor (in you print them). But that's becausey
is transposed after it was created (and this only changed the logical order, not the physical), and thus has custom strides.But you could still store both x and y without copy in a FixedShapeTensor array. The difference is that
x
would be stored as shape (2, 3), and y would be stored as (3, 2). And assume that in this dummy example the dimensions are called A and B, and if you want to keep track of the correct logical order, you would store the dimension names forx
as["A", "B"]
and fory
as["B", "A"]
. Then afterwards, after reading such data and the application knows it always wants the data in (A, B) order, it can transpose the data read from the storedy
(just as you did when creatingy
)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.
Btw I fixed a bug in my script ...
I understand that there exist a permutation of dimensions that allows me to get a "row major" format. I think it doesn't change how you store the permutation information, ie via dimension names or stride. It felt like a natural concept to me to store
stride
, as this would allow just provide a better generalisation IMO. But I do understand if the current extension would focus on pure row_major.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.
OK, I understand (we might have been talking past each other a bit, as I was assuming you want to have
strides
to allow zero-copy for all cases, while I tried to convince you that it's not needed).It's certainly true that we could store strides, but I am not sure it would be a better generalization of (or a full replacement for) dimension names.
Consider for example that you have channels-last physical data (NHWC), but you view it as channels-first logically (NCHW). To store the data with the logical dimension order, this would requires a
strides
parameter. But assume you only store the strides in theFixedShapeTensor
type and not the dimension names, then when consuming that data, you know the strides associated with it, but you still don't know for sure what the dimensions mean (because both NHWC viewed as NCHW, or NCHW viewed as NHWC would give you custom strides). Of course, if you know where the data is coming from and you know that it's from a pytorch context, then you can assume that the logical order is NCHW (that's how pytorch always shows it: "No matter what the physical order is, tensor shape and stride will always be depicted in the order of NCHW"), and that information combined with the strides ensures you know if the physical layout is channels-first or last.But that requires application-specific context to know that. While if you store the dimension names that match the order assuming a row-major layout, then you can infer the same information (and how to transpose it to get your desired logical order), but without requiring this application-specific knowledge (assuming different applications would use consistent dimension names, so you can recognize those).
So my current understanding is that dimension names are the more generalizable information.
In addition, pushing the strides logic (how to translate the given dimension order and your desired dimension order to strides) to the application to deal with, keeps the implementation of the FixedShapeTensorType itself simpler, not requiring every implementation to deal with custom strides.