3 ms·

The CPU works on 64-bits. But the memory works on 512-bit / 64 byte cache lengths or DDR4 bursts. An unaligned access could be across 2 cache lines or 2 DDR Bu

The CPU works on 64-bits. But the memory works on 512-bit / 64 byte cache lengths or DDR4 bursts. An unaligned access could be across 2 cache lines or 2 DDR Bursts. Or across a page table (I think 4096-bytes??) Or other higher level of organization requiring multiple accesses under the hood. X86 does the easy thing and takes two or more clock ticks to read. But aligned accesses remain faster, likely for these low level groupings of bytes. Some architectures straight up do not allow unaligned reads and force the programmer to read two registers and then extract the unaligned data. ------- In particular, reading or writing across two cache lines can be disastrous loss of efficiencies. The memory system needs to lock / MESI indicate both cache blocks. If one (or the other) memory location is still locked by another thread / CPU core, you'll get false sharing. As such, a common practice is to 64-byte / 512-bit align your memory accesses in heavily multithreaded code.

kzrdude 3y ago
And sometimes 128-byte because the some part of the cache system is reading two cache lines at a time in contemporary x86-64 if I understand correctly.
- loeg 3y ago
  It was a really big problem for early x86-64 CPUs, I believe. My hearsay recollection is that the cache prefetcher would pretty much always load pairs of adjacent cache lines.
dist1ll 3y ago
Note: unaligned doesn't always mean cache-line splitting. Unaligned 64-bit loads & stores within a cache line incur no performance penalty on modern Intel architectures IIRC. Also, reading a cache-line in shared MESI state should not cause false sharing degradation, only writing.
- pclmulqdq 3y ago
  Unaligned doesn't always mean cache-line splitting, but aligned means never splitting cache lines. Also, you're correct that aside from caching effects, unaligned loads and stores generally carry no penalty on x86. This is one of the smarter (IMO) things that Intel/AMD have done to keep x86's market share.
- gpderetta 3y ago
  It can still penalize another writer by forcing its exclusive line into shared. It is not as expensive as a concurrent writes but it is a significant measurable overhead to what would otherwise be a write private line.
  - deleted 3y ago
    [deleted]
o11c 3y ago
> Some architectures straight up do not allow unaligned reads and force the programmer to read two registers and then extract the unaligned data. That's largely obsolete for architectures that still get used now that individual transistors are cheap, since it turns out that it's much more efficient to do it in silicon, even if such accesses are pretty rare.
codedokode 3y ago
But the probability that 16-byte value will be split over two 64-byte cache lines is not very high (I think it is 1/8). Is it worth optimizing for an unlikely case?

kzrdude 3y ago

And sometimes 128-byte because the some part of the cache system is reading two cache lines at a time in contemporary x86-64 if I understand correctly.

loeg 3y ago
It was a really big problem for early x86-64 CPUs, I believe. My hearsay recollection is that the cache prefetcher would pretty much always load pairs of adjacent cache lines.

dist1ll 3y ago

Note: unaligned doesn't always mean cache-line splitting. Unaligned 64-bit loads & stores within a cache line incur no performance penalty on modern Intel architectures IIRC. Also, reading a cache-line in shared MESI state should not cause false sharing degradation, only writing.

pclmulqdq 3y ago
Unaligned doesn't always mean cache-line splitting, but aligned means never splitting cache lines. Also, you're correct that aside from caching effects, unaligned loads and stores generally carry no penalty on x86. This is one of the smarter (IMO) things that Intel/AMD have done to keep x86's market share.
gpderetta 3y ago
It can still penalize another writer by forcing its exclusive line into shared. It is not as expensive as a concurrent writes but it is a significant measurable overhead to what would otherwise be a write private line.
- deleted 3y ago
  [deleted]

o11c 3y ago

> Some architectures straight up do not allow unaligned reads and force the programmer to read two registers and then extract the unaligned data. That's largely obsolete for architectures that still get used now that individual transistors are cheap, since it turns out that it's much more efficient to do it in silicon, even if such accesses are pretty rare.

codedokode 3y ago

But the probability that 16-byte value will be split over two 64-byte cache lines is not very high (I think it is 1/8). Is it worth optimizing for an unlikely case?