Data alignment: Straighten up and fly right (2005)
ibm.com
ibm.com
However, it really is just memories. Nowadays, total memory consumption usually trumps alignment, so it tends to be better to pack your data as tightly as possible and let the CPU extract the bits it needs, which particularly x86 is very good at. Packing is particularly effective if manage to get everything onto a cache line.
Reason being the gulf between CPU and memory performance. If you save just one memory access you can pay for that with a lot of internal CPU operations.
Conversely, if you have a structure shared between different threads/cores, you probably want to make sure they do not share a cache line.
And yes, atomics should definitely be aligned.
which particularly x86 is very good at
That's largely because x86 never had aligned instructions, and whose sizes are simply multiples of bytes, so quite early in its development it already ahd efficient ways of extracting the needed set of bytes from memory regardless of alignment.
Yep. Which makes you wonder if maybe this sort of thing should be surfaced somehow.
More interesting is the question of whether to do traditional C struct style "row first" data layout, or whether to do "column first" data layout which may be better for use with SIMD.
ARMv7 supports unaligned access but not on all operations (e.g. LDM or STM don't support it). And the operation will simply be split into multiple aligned accesses, which are not necessarily atomic.
ARM64 further expands this, according to ARM
> Except for exclusive and ordered accesses, all loads and stores support the use of unaligned addresses when accessing normal memory.
On ARMv5, some operations could be given unaligned addresses but would round them down, and possibly rotate the result.
ARMv6 is/was switchable between ARMv7 and ARMv5 behaviour.
Also ARMv7+ can be configured to fault on all unaligned access.
This only really matters for broken programs which do unaligned accesses without telling the compiler about it (which can also trip you up, though more rarely, under x86, if the compiler decides to use a simd instruction). As Steve says, it only affects a really tiny set of programs, which can have their bugs fixed.
Even in 2019, finding out the erase size is still a problem.
Personally, I run a benchmark script whenever I provision a server. It explore a small set of values to find the ideal filesystem parameters.
It is not as complete as doing several iteration of random 4k iops with fio on the full partition, but a good enough rule of thumb to avoid misconfigurations.