---
title: "The Same 128 Useful Bytes Can Need Four or Thirty-Two GPU Memory Transactions"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/gpu-warp-memory-coalescing-requested-transactions"
last-updated: "2026-10-20"
---

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

Leviathan Systems — Technical content
Published 2026-10-20; updated 2026-10-20.

Equal logical read sizes can place different demands on GPU memory access units. Under CUDA C++ Best Practices Guide 13.4's compute-capability 6.0-and-higher rule, one warp instruction reading 32 distinct four-byte words can require four or thirty-two 32-byte transactions, depending on the addresses. Both cases deliver 128 useful bytes. These modeled transaction counts explain an access pattern; they establish neither observed HBM traffic nor an eightfold application-speed difference.

## 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](https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html#coalesced-access-to-global-memory)

## 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](https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html#coalesced-access-to-global-memory)

## 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](https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html#coalesced-access-to-global-memory)

## 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](https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html#coalesced-access-to-global-memory)

## 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](https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html#coalesced-access-to-global-memory)

## 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](https://docs.nvidia.com/nsight-compute/ProfilingGuide/index.html#memory-tables)

## 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](https://docs.pytorch.org/docs/2.14/tensor_view.html), [N1](https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html#coalesced-access-to-global-memory)

## 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](https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html#coalesced-access-to-global-memory)

## 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](https://www.leviathansystems.co/services/rack-and-stack)

## Primary sources

- [N1 — NVIDIA CUDA C++ Best Practices Guide 13.4 — coalesced global-memory access and bandwidth](https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html#coalesced-access-to-global-memory). Checked 2026-10-20. Sections 10.2.1-10.2.1.4 support the compute-capability 6.0-and-higher, four-byte-word scope. Sections 9.2.2-9.2.3 distinguish useful-byte rates from actual transfers. Historical product measurements and optimization recipes are not adopted.
- [N2 — NVIDIA Nsight Compute Profiling Guide — Memory Tables](https://docs.nvidia.com/nsight-compute/ProfilingGuide/index.html#memory-tables). Checked 2026-10-20. Updated August 27, 2026. Sections 2.11.2-2.11.5 define requests, sectors, cache misses and device-memory bytes. Counter meanings remain tied to their named level and access type.
- [P1 — PyTorch 2.14 — Tensor Views](https://docs.pytorch.org/docs/2.14/tensor_view.html). Checked 2026-10-20. Created and updated May 7, 2026. Supports shared storage, changed interpretation without value movement and noncontiguous views; it does not prescribe a consuming kernel's thread mapping.
- [L1 — Leviathan Systems — Rack & Stack / Colocation](https://www.leviathansystems.co/services/rack-and-stack). Checked 2026-10-20. Agreed equipment mounting, IT cabling, labels and physical installation records. Software bring-up and full system commissioning are outside standard physical installation.

## Related Leviathan resources

- [Arithmetic intensity and GPU bandwidth at a named memory boundary](/articles/gpu-memory-bandwidth-arithmetic-intensity-roofline)
- [Inline memory compression: transferred representation versus capacity](/articles/gpu-inline-memory-compression-bandwidth-versus-capacity)
- [PyTorch tensor views, strides and shared storage](/articles/pytorch-tensor-views-strides-shared-storage)
- [GPU activity versus resident-warp occupancy](/articles/gpu-activity-utilization-versus-sm-warp-occupancy)
- [Compare completed GPU workload benchmark evidence](/articles/which-gpu-is-fastest-workload-benchmarks)
- [Review physical rack-and-stack installation scope](/services/rack-and-stack)
- [Discuss physical installation of separately selected equipment](/contact?service=rack-and-stack&from=%2Farticles%2Fgpu-warp-memory-coalescing-requested-transactions)

## Need installation for the selected equipment?

Share the equipment, site, released plans, target window and physical handoff requirements to discuss an installation scope and availability.

[Discuss the scope](/contact?service=rack-and-stack&from=/articles/gpu-warp-memory-coalescing-requested-transactions)