Why are datatypes self-aligned?

Question

I understand data structure alignment restrictions exist to optimize memory accesses because modern CPUs fetch memory in word-sized (or multiples of word-size) chunks. This would make me think that the that most optimal way to align data is to (fixed) word boundaries.

For example, consider the following structs on a 32-bit machine (compiled with gcc v6.2.0; CFLAGS: -Wall -g -std=c99 -pedantic):

struct layoutA {
    char a;     /* start: 0; end: 1; padding: 3 */
    uint32 b;   /* start: 4; end: 8; padding: 0 */
    uint64 c;   /* start: 8; end: 16; padding: 0 */
};

/* sizeof(struct layoutA) = 16 */

struct layoutB {
    uint32 b;    /* start: 0; end: 4; padding: 4 */
    uint64 c;    /* start: 8; end: 16; padding: 0 */
    char a;      /* start: 16; end: 0; padding: 3 */
};

/* sizeof(struct layoutB) = 24 */

Due to the self-alignment restriction, c forces the second struct to align itself to the 8-byte boundary instead of the word boundary (4-byte).

How does this reconcile with the original reason for alignment - memory optimization. It would appear that placing c at 4 should also help the CPU read it in 2 accesses (similar to the current case where it needs to access 2 words (at 8 and 12) to get the entire doubleword.

How does self-alignment optimize memory access? In other words, what benefit do we gain in the second case to justify the losing the space due to self-alignment?

C does not enforce anything. That's implementation specific. Your question is not clear. What do you mean with "self-alignment"? And how do you get the values you assume? — too honest for this site
@Olaf: Yes. I just used C as an example. I realize that the question itself is platform-dependent. Do you know of a more appropriate tag for this? — Shrikant Giridhar
I don't see what your problem is. Read comments completely, not just the first 1-2 sentences. — too honest for this site
It is a simple rule, the struct members still need to be aligned when the structs are stored in an array. The only way that can work is when it gets artificially made longer by adding padding to the end of the struct. So that the start address of the next struct is properly aligned. Since the c member needs to be aligned to 8, the struct must have a size that is a multiple of 8. 24 is the next smallest suitable size. — Hans Passant
Your question contradicts itself. You seem to be aware that accessing data at naturally-aligned addresses is the most performant. That is the answer to "why does my compiler do this?" Also, if memory is more of a concern than performance, you can mark the structure as packed, or reorder it yourself. — Jonathon Reinhart

chqrlie chqrlie · Accepted Answer · 2016-10-30T14:29:03

Alignment is implementation specific. Its primary purpose it not optimisation: on some architectures, word accesses must be aligned or they invoke undefined behavior.

On Intel architectures, most unaligned accesses can be configured to work correctly, but programmer should not rely on that and compilers certainly don't. When unaligned accesses are supported, they are usually slower than aligned accesses, hence the optimisation effect.

If type uint64_t happens to require self-alignment, as seems to be the case on the target system, the layout for struct layoutB uses more memory than struct layoutA, but both require 64-bit alignment.

The benefit we get from self-alignment is code correctness. On a 32 bit architecture that does not require self-alignment of 64-bit integer variables, it is optional but you still get an advantage as both 32-bit parts would come from the same cache line.

You could use packing attributes or pragmas to force a specific layout and run benchmarks to assess the impact on your target system. It is tricky and may or may not show a difference.

A a conclusion: alignment is implementation defined and should be left to the compiler, but careful ordering of structure members may yield better memory usage and significant savings for large arrays of structures.

Why are datatypes self-aligned?

1 Answers