Global-memory coalescing

Write the address used by each active lane for one issued memory instruction. For a row-major FP32 tensor, adjacent lanes accessing adjacent columns often request consecutive four-byte words. A column traversal can instead separate lanes by a whole row stride. The important pattern is the set of addresses serviced together, not whether the source code contains a simple loop or a familiar tensor operation. Predication and boundary tiles change which lanes participate, so analyze partial warps as well as the interior case.

Under the stated compute-capability model, count the distinct aligned 32-byte sectors needed to cover the requested words. Permuting lanes within the same sectors does not necessarily change that count. Fewer active lanes do not automatically reduce it if their words remain spread over the same sectors. An aligned base allocation also does not guarantee every tensor view is aligned: an offset slice or a row pitch can shift the starting address. Verify effective addresses after indexing and view transformations.

Thirty-two adjacent four-byte loads request 128 useful bytes. If the first word begins on a 32-byte boundary, four sectors cover them. Starting one word later can require five sectors for the same useful payload. Strided accesses can use only part of each fetched sector. These counts describe one access request under the simplified sector model; they are not a promise that an identical number of bytes reaches external memory after caching, reuse, compression, or implementation-specific effects.

Coalescing is also independent of correctness. A highly coalesced access can still be out of bounds, race with another operation, or violate alignment requirements for the compiled instruction. Conversely, a scattered access may be correct and unavoidable for the algorithm. Improve layout only while preserving the logical mapping of tensor elements. Compare numeric outputs, including edge dimensions and noncontiguous inputs, before interpreting a bandwidth improvement as a successful optimization.

Use compiler and profiler evidence to establish the actual instruction widths, active lanes, and memory behavior. Compare otherwise equivalent tensor kernels at representative sizes, separating warm cache reuse from cold streaming behavior. A coalescing change can affect register pressure, shared-memory use, and occupancy, so the fastest source layout is not determined by sector count alone. Record the target GPU architecture, toolkit, and kernel launch shape whenever reporting a result. CUDA version and compute capability describe different parts of that environment.

The Roofline lab illustrates only a possible traffic consequence. Reset, set operational intensity to 2 FLOP per byte and bandwidth to 80 GB/s, predict the synthetic ceiling, then Step. For a new run, Reset and set both intensity to 1 and bandwidth to 80, predict, then Step. Treat the lower intensity as an assumed doubling of bottleneck bytes at fixed useful arithmetic. The model’s compute ceiling is fixed at 1000 GFLOP/s; it does not count sectors or benchmark a GPU.