Why does reading one byte from memory load 64 bytes?

Reading one byte loads sixty-four because the hardware has no smaller operation. Memory moves fixed blocks of sixty-four bytes, aligned to a sixty-four-byte boundary, so the request for one byte can only be served by fetching the block that contains it. There is no transaction anywhere in the machine that moves four bytes: the path from memory to processor, the caches, and the protocol that keeps cores consistent all speak in blocks. The cost is dominated by getting to the memory chip and opening a row there, not by the number of bytes sent back, so the other sixty-three bytes ride along for almost nothing.

Price one fetch. The request takes 15 ns to leave the processor. Activating a row inside the memory chip takes another 45 ns, so 60 ns have gone before any data moves. The first eight bytes arrive at 65 ns; the remaining fifty-six arrive at 80 ns. The extra fifty-six bytes therefore cost 15 ns, about 0.27 ns per byte, while the first eight, if you divide the 65 ns by 8, cost 8.125 ns per byte. The full sixty-four bytes cost 80 ns against 65 ns for the first eight: eight times the data for 15 ns more. That is the trade: a small stake against another 65 ns of latency if the neighbours are needed later.

Check the first three rows against $b = n \cdot l$. A million contiguous four-byte values occupy 4,000,000 bytes. Divide by 64: $4{,}000{,}000 / 64 = 62{,}500$ blocks. Traffic is $62{,}500 \times 64 = 4{,}000{,}000$ bytes. At a stride of 16 bytes, the values span 16,000,000 bytes, so $16{,}000{,}000 / 64 = 250{,}000$ blocks and $250{,}000 \times 64 = 16{,}000{,}000$ bytes. At a stride of 64 bytes, each value lands in a new block: $1{,}000{,}000 \times 64 = 64{,}000{,}000$ bytes. The last column moves from 1 ns to 10 ns per value, a factor of $10 / 1 = 10$. Same arithmetic, same number of values, sixteen times the traffic and ten times the time.

The block bet fails when the next access lands in a new block and uses only a few bytes of it. A stride of 256 bytes or 4,096 bytes gives the same 64,000,000 bytes of traffic as a stride of 64, because one block per access is the worst case for traffic. The further rise to 38 ns at a stride of 4,096 comes from translation misses, not from the block size: $4{,}096 / 64 = 64$ blocks are skipped between accesses. Going in order also turns on the prefetcher, which watches a constant stride and fetches ahead, so sequential access beats the latency numbers alone. A pointer chase forfeits that: the next address is inside the current block, so the prefetcher cannot see it and the misses cannot overlap. The prefetcher also stops at the boundaries of the mapped region, typically every 4 KB, which is $4{,}096 / 64 = 64$ blocks, and starts again. If records are packed several to a block, the waste per record falls; if one record spans several blocks, it rises. The fixed unit is still the block, so the traffic is still $n \cdot l$.