The Same 128 Useful Bytes Can Need Four or Thirty-Two GPU Memory Transactions

Count addresses for one instruction

A CUDA warp contains 32 threads. For the access considered here, every thread participates in the same global-memory load instruction. Coalescing concerns how that instruction's addresses group into memory access units. It does not combine arbitrary reads across a whole kernel.

CUDA C++ Best Practices Guide 13.4, section 10.2.1, describes the compute-capability 6.0-and-higher rule: count the 32-byte transactions needed to serve the participating threads. The guide uses this unit whether global loads are cached in L1 or not. Its older compute-capability 5.2 discussion has different conditions and is outside this example.

This address grouping is separate from NIC interrupt coalescing, which concerns notifications. It also answers a different question from warp occupancy: how addresses group, rather than how many warps reside on an SM.

References: [N1]

MC-213: fix the payload and identify each unit

Consider an original address-bookkeeping example, MC-213. Let B be a byte address on a 32-byte boundary in one allocation large enough to contain every address below. Number the warp's threads t = 0 through 31. Each reads one distinct four-byte word in one instruction, so the useful payload is always 32 x 4 = 128 bytes. The allocation stays the same across the three patterns.

Define unit 0 as bytes B + 0 through B + 31, unit 1 as B + 32 through B + 63, and unit k as B + 32*k through B + 32*k + 31. All endpoints are inclusive. Count each touched unit once, even if several threads read different words within it.

The following counts model service-unit coverage. They are original calculations from stipulated addresses, without an executed kernel or a named GPU's benchmark.

References: [N1]

Offsets 4*t: eight words fit in each of four units

First, thread t reads the word starting at B + 4*t. The starting offsets are 0, 4, 8 and so on through 124; the last word ends at offset 127.

Threads 0-7 read bytes 0-31 relative to B, filling unit 0. Threads 8-15 fill unit 1, threads 16-23 fill unit 2, and threads 24-31 fill unit 3. Each unit contains eight requested four-byte words.

The touched-unit set is {0, 1, 2, 3}. Four units cover 4 x 32 = 128 bytes, all useful to this instruction. The equality comes from the address membership, not merely from dividing 128 by 32.

References: [N1]

Offsets 32*t: one word occupies each of thirty-two units

Now let thread t read the word starting at B + 32*t. The starts are offsets 0, 32, 64 and so on through 992. Each word occupies the first four bytes of its own unit: thread 0 touches unit 0, thread 1 touches unit 1, and thread 31 touches unit 31.

The touched-unit set is {0, 1, 2, ..., 31}. The instruction still requests 32 distinct words and 128 useful bytes, but needs 32 units covering 32 x 32 = 1,024 bytes. Within each unit, 28 bytes are unused by this instruction.

Useful payload divided by covered bytes is now 128 / 1,024 = 12.5%, compared with 100% in the first pattern. These are example-specific coverage fractions. Unused here does not mean unused by every later instruction.

References: [N1]

Offsets 4 + 4*t: adjacency can still touch five units

Return to adjacent words, but shift every start by four bytes. Thread t now starts at B + 4 + 4*t. The requested region runs from offset 4 through offset 131, still exactly 128 bytes.

Unit 0 contains the seven words read by threads 0-6, at offsets 4 through 31. Units 1, 2 and 3 each contain eight words, read by threads 7-14, 15-22 and 23-30 respectively. Thread 31 reads offsets 128-131 in unit 4.

Five units therefore cover 160 bytes. The instruction uses 128 / 160 = 80% of that coverage; bytes 0-3 and 132-159 are outside its requested region. The unit boundaries explain the extra count despite unchanged payload and adjacent words.

References: [N1]

A transaction count is not a cache-miss or HBM-bus count

NVIDIA's Nsight Compute Profiling Guide, updated August 27, 2026, distinguishes warp instructions, requests and sectors. Its L1/TEX table describes one request per global-load instruction and a byte account equal to the sector count multiplied by 32. Thus four modeled 32-byte units do not mean four warp instructions or necessarily four entries in a counter named Requests.

The guide separately reports L1 sector misses sent to L2, L2 misses sent onward and bytes transferred between L2 and device memory. A sector served from cache need not reach HBM for that access. Reuse by another instruction or warp can also change subsequent traffic.

MC-213 supplies no cache state, miss observations, other reads or writes, or elapsed time. Its 128-, 160- and 1,024-byte coverage totals therefore cannot be relabeled as observed HBM-bus traffic. The hierarchy and the actual counter boundary remain necessary evidence.

Likewise, 32 / 4 = 8 is a ratio of modeled unit counts. Neither case has a duration, and the example describes only one instruction. It supplies no eightfold kernel or application speedup.

References: [N2]

Tensor layout does not supply the missing thread mapping

PyTorch 2.14's Tensor Views documentation, updated May 7, 2026, explains that a view shares its base's data and can change its interpretation without moving values. A view of a contiguous tensor can be noncontiguous. Those properties describe storage and logical indexing.

Coalescing additionally needs the mapping from participating threads to addresses for the particular instruction. In MC-213, the same enclosing allocation permits either the 4*t or 32*t pattern. Knowing that its bytes form a contiguous allocation does not choose between those mappings.

A contiguous tensor label alone therefore cannot certify coalescing, and a strided view label alone cannot establish thirty-two transactions. The consuming implementation determines which indices the warp accesses together. Use the related tensor-views guide for storage sharing and copy accounting.

References: [P1][N1]

Ask which bytes the comparison actually counts

Suppose two submissions report the same logical read volume on equipment with the same nominal memory bandwidth. MC-213 shows why those facts leave the address-grouping demand unresolved. Equal allocation sizes add no missing thread-to-address information either.

Ask the platform owner to identify the operation, GPU compute capability, software version, participating-thread count, per-thread access width and address mapping behind the claim. For reported traffic, retain the exact counter, memory level, access types and observation interval. Establish whether a number is requested logical bytes, sector coverage or measured device-memory traffic before comparing rates.

CUDA's effective-bandwidth calculation uses bytes read and written divided by elapsed time. A useful read-byte count alone supplies no rate. A measured rate still needs its numerator and boundary identified before it can explain effective use of a nominal interface bandwidth.

For changes in transferred representation, see the related inline-compression article. The Roofline guide explains arithmetic intensity at a named memory boundary. Use those mechanisms separately when relevant. For equipment selection, require comparable completed-work evidence from the appointed platform team rather than converting MC-213's coverage ratio into a performance forecast.

References: [N1]

Connect separately selected equipment to physical installation

If the selected GPU equipment also needs physical installation, Leviathan's rack-and-stack service provides a route to discuss agreed mounting, IT cabling, labels and installation records. Use the related project inquiry with a nonconfidential equipment list, site, released rack and cable plans, target window and required handoff. Application profiling, software tuning and performance acceptance remain with the appointed platform team.

References: [L1]