2026-06-18
Inside every DRAM chip, the actual storage is a 2D grid of capacitors organized into rows (typically 8KB wide) and columns. But you can't read a capacitor directly — the charge is too small. Instead, every bank has a row buffer: a strip of sense amplifiers that latches an entire row at once. All reads and writes actually touch the row buffer, not the cells themselves.
This creates three dramatically different access scenarios:
That's roughly a 3x latency swing based purely on whether the previous access touched the same row. And because activating a row is destructive (it drains the capacitors and refreshes from the sense amps), you literally cannot skip the precharge step on a conflict.
Concrete example: Walking a 1GB array sequentially gives you ~128 row buffer hits per row (8KB / 64B cache line). Random access into the same array gives you almost guaranteed row conflicts on every access — the DDR5 spec lists tRC (row cycle time) around 45ns, so you're capped at ~22M accesses/sec per bank. Sequential streaming on the same hardware hits 100M+ accesses/sec per bank. Same bytes, same chip, ~5-10x throughput difference.
Why banks exist: Modern DRAM has 16-32 banks per rank precisely so the memory controller can overlap the precharge/activate latency of one bank with column accesses on another. This is why memory controllers aggressively interleave addresses across banks — a 4KB page typically spans multiple banks so even "random" access within a page gets some parallelism.
Rule of thumb: If your working set's stride matches the row size (often 8KB), you'll get worst-case row conflicts. The classic pathology is striding through a column of a large matrix where each element lands in the same bank but a different row. Either tile your access pattern, or transpose.
The page policy the memory controller uses matters too: open-page keeps rows open speculating on locality (great for sequential), close-page precharges immediately (better for random). Server BIOSes often expose this.