Memory layout in Zig with formulas

Memory layout in Zig with formulas(raymondtana.github.io)

140 points by raymondtana 116 days ago | 28 comments

raymondtana 116 days ago |

I've been learning Zig, and needed a refresher on memory layout (@sizeOf and @alignOf).

Wrote this blog post to summarize what I think are the right ways to understand alignment and size for various data types in Zig, just through experimentation.

Let me know any and all feedback!

repiret 116 days ago | |

> CPUs fetch data from memory in fixed-size blocks of so-many bytes, and performance degrades when data is misaligned.

A memory bus supports memory transactions of various sizes, with the largest size supported being a function of how many data lines there are. The following two statements are true of every memory bus with which I'm familiar, and I probably every bus in popular use: (1) only power-of-two sizes are supported; (2) only aligned transactions are supported.

Arm, x86, and RISC-V are relatively unique among the multitude of CPU architectures in that if they are asked to make an unaligned memory transaction, they will compose that transaction from multiple aligned transactions. Or maybe service it in cache and it never has to hit a memory bus.

Most CPU architectures, including PPC, MIPS, Sparc, and ColdFire/68k, will raise an exception when asked to perform a misaligned memory transaction.

The tradition of aligning data originated when in popular CPU architectures, if you couldn't assume that data was aligned, you would need to use many CPU instructions to simulate misalinged access in software. It continued in compilers for Arm and x86 because even though those CPUs could make multiple bus transactions in response to a single mis-aligned memory read, that takes time and so it was much slower.

I don't know for sure, but I would expect that on modern x86 and high performance Arm, the performance penalty is quite small, if there's any at all.

Joker_vD 116 days ago | | |

It's small, but not unnoticeable... depending on the exact size of the workload and the amount of computation per element. In fact, for huge arrays it may be beneficial to have structs packed if that leads to less memory traffic.

[0] https://jordivillar.com/blog/memory-alignment

[1] https://lemire.me/blog/2012/05/31/data-alignment-for-speed-m...

[2] https://lemire.me/blog/2025/07/14/dot-product-on-misaligned-...

dnautics 116 days ago | |

i could be wrong but i believe the zig compiler reserves the right to lay things out differently depending on compilation mode? especially debug. unless it's extern or packed, in which case the layout will be defined.

rvrb 116 days ago | | |

`extern` and `packed` container types have well defined layouts. a regular `struct` is an "auto" layout - and the compiler can and will rearrange whenever it wants.

if you need a well defined layout, use `extern`. if your struct makes sense to represent as an integer, use `packed`. I think it is often ill advisable to use `packed` otherwise.

you can explore this yourself on the Type info returned from @TypeInfo(T):

https://ziglang.org/documentation/master/std/#std.builtin.Ty...

thechao 116 days ago |

I know this is a bit cursed; but, I always wanted a bitfield-on-steroids construct:

    struct Dang : bits 64    // 64 bits wide, int total
    {
        foo : bits 5 @ 0;    // 5 bits wide at bit offset 0
        bar : bits 5 @ 0;
        baz : bits 16 @ 4;   // 16 bits wide at bit offset 4
        tom : bits 11 @ 32;
    };

travisgriggs 116 days ago |

> I imagine just about any computer science major would have learned the rules of memory layout according to some kind of C-like compiler.

I have worked with a number of fresh grads over the last ten years. I can think of one who may have had a good handle on this. At best the rest range from “vague memory recall about this” to a blank stare.

On the flip hand, it’s something someone can pick up pretty quickly if motivated.

andsoitis 116 days ago |

Memory layout of a data structure in various programming languages: https://rosettacode.org/wiki/Memory_layout_of_a_data_structu...

ivanjermakov 116 days ago |

I also had to learn struct alignment the hard way working on WebGPU path tracer and struggling to understand why struct fields not aligning (ironically).

bk496 116 days ago |

useful!

struct Dang : bits 64 // 64 bits wide, int total { foo : bits 5 @ 0; // 5 bits wide at bit offset 0 bar : bits 5 @ 0; baz : bits 16 @ 4; // 16 bits wide at bit offset 4 tom : bits 11 @ 32; };

union Dang { uint64_t : 64; // set total width uint8_t foo : 5; uint8_t bar : 5; struct __attribute__((packed)) { uint8_t : 4; uint16_t baz : 16; }; struct __attribute__((packed)) { uint32_t : 32; uint16_t tom : 11; }; };

#define OFFSET_BITFIELD_DECLARE(NAME, SIZE) \ union NAME { \ uint64_t : SIZE #define BITFIELD_MEMBER(NAME, SIZE, OFFSET) \ struct __attribute__((packed)) { \ uint64_t : OFFSET; \ uint64_t NAME : SIZE; \ } #define OFFSET_BITFIELD_END() } OFFSET_BITFIELD_DECLARE(Dang, 64); BITFIELD_MEMBER(foo, 5, 0); BITFIELD_MEMBER(bar, 5, 0); BITFIELD_MEMBER(baz, 16, 4); BITFIELD_MEMBER(tom, 11, 32); OFFSET_BITFIELD_END();