Logical tensors and physical layouts
Track shapes, strides, and layout constraints without mistaking a view for a required data copy.
On this page
The question for today
What you’ll understand
- Compute a physical offset from logical indices and explicit strides.
- Distinguish a transpose view from materialized transposed storage.
- Explain why layout propagation is a graph-wide constraint problem.
A tensor's logical shape describes its indexed values, while a layout describes where those values live. A compiler can sometimes change physical order without changing the mathematical tensor, or represent a transpose through metadata instead of moving bytes. Those choices affect producers, consumers, library interfaces, and aliasing. Trace the index-to-storage mapping rather than assuming that row-major is always required or that every transpose necessarily allocates a copy.
Indices need an explicit mapping to storage
For a two-dimensional strided buffer, multiply each logical index by its element stride, add the base offset, then multiply by bytes per element for a byte displacement. Bounds and storage extent still matter. Strides may describe a dense array, a slice, a broadcasted view, or another mapping with aliasing. A shape alone does not establish contiguity, uniqueness, alignment, or how many allocated bytes the view owns. Distinguish element strides from byte strides in every formula.
A transpose view can exchange shape dimensions and strides while retaining the same underlying bytes. That is different from copying elements into a new dense buffer with transposed logical order. Whether a consumer accepts the view depends on its layout contract and the compiler's ability to lower the access pattern. A library call may require or prefer a specific arrangement, making a conversion worthwhile or necessary even when a mathematical operation itself is layout independent.
One local choice changes neighboring costs
An elementwise consumer can often follow a producer's chosen layout, avoiding a conversion. A reduction, matrix product, or external library boundary can impose different access or layout requirements. If one value has several consumers, a layout favorable to one may disadvantage another. Propagation must account for the whole use graph, including copies, packing, and lifetime extension. The cheapest representation for one operation in isolation can increase total execution time or memory.
Layouts also affect which lanes access adjacent memory and how tiles are distributed across hardware. A physical address permutation that is legal for values may change coalescing, bank behavior, or vector loads. These are target-specific performance questions, not logical tensor equivalences. OpenXLA documents shape and layout separately; exact internal attributes and pass behavior can evolve. Record the compiler revision and target when measuring layout decisions instead of treating a current dump format as a permanent API.
Verify mappings at awkward shapes
Test non-square shapes, sliced inputs, nonzero offsets, and consumers with explicit layout restrictions. A square matrix or a corner index can accidentally yield the same offset under different mappings, hiding a mistake. Compare every logical output with a reference that understands the same view semantics. Inspect allocation and copy behavior separately from value correctness: removing a conversion is a performance result only if every consumer still receives the required values under valid storage and lifetime rules.
The matrix lab offers only a geometric contrast. Reset and set both a=1, b=1, predict determinant 1 and the shear, then Step. Its continuous two-dimensional transform does not describe a tensor's strides, lane distribution, or allocated byte order. Playback interpolates geometry while readouts retain the final selected matrix. Explain why preserving area in that diagram cannot prove that an arbitrary tensor layout preserves logical indexing or satisfies a downstream library's storage contract.
Work it through
One logical index, two dense storage orders
A 3×4 tensor uses four-byte elements and zero base offset. Compare logical element(2,1) in dense row-major strides(4,1) and dense column-major strides(1,3). Assume separate correctly populated allocations.
Row-major element offset is 2×4+1×1=9, producing byte displacement 36. Column-major offset is 2×1+1×3=5, producing displacement 20.
Both allocations contain twelve elements and 48 payload bytes, but the same logical element occupies different physical positions. Equal allocation size does not establish equal storage order.
A transpose view of the row-major tensor has shape 4×3 and strides(1,4). Its logical index(1,2) maps back to offset 1+8=9 without moving data, provided consumers support that view and lifetime.
Logical values can be preserved through a changed mapping, but metadata-only views and physical copies have different interface and resource consequences.
The living notebook
Explore the model
Interactive lab · matrix
Geometry does not define tensor storage
Reset, set a=1, b=1, predict determinant 1 and a shear, then Step. This geometric matrix family is not a tensor layout, stride, lane-mapping, or copy-cost model.
- Area scale · det A
- 1.4
- Singular values · σmax, σmin
- 1.597, 0.876
- Condition number · κ₂(A)
- 1.823
The selected matrix is A = [[a,b],[0,1]]. Playback interpolates geometry between the identity and A; readouts always describe A. Its determinant is a and its singular values come from AᵀA. Positive a makes every supported matrix invertible. This two-dimensional family is not a general eigensolver or a learned network. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forVerify the actual logical-index-to-byte mapping at each producer-consumer boundary.
Pause & reason
Check your understanding
Your turn
Try it yourself
A 2×5 row-major four-byte tensor has element strides(5,1) and base offset three elements within a valid larger allocation. Find the byte displacement for logical index(1,2), and explain why the shape alone was insufficient.
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Include the base offset before converting element offset to bytes.
Compare with the solution
Element offset is 3+1×5+2=10, so byte displacement is 40. Shape 2×5 did not specify the base offset or strides, and therefore could not determine that location by itself. Validity also requires the larger allocation to cover the accessed element and the view's lifetime; the offset arithmetic does not prove either property.
Keep the idea
Take it with you
- Logical shape and physical layout carry different information.
- A view can avoid a copy only when consumer and ownership contracts permit it.
- Layout costs and constraints propagate through the entire use graph.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.