Mastering Cache-Conscious Data Layout in Rust: Field Zoning and the 128-Byte Rule
Cache-Conscious Data Layout in Rust: Field Zoning, False Sharing, 128-Byte Rule
I explore how to design high-performance multi-threaded structures in Rust by deliberately zoning fields based on which core accesses them. By separating producer and consumer hot paths and applying the 128-byte alignment rule, we eliminate false sharing that silently serializes cores. Using a single-producer single-consumer ring buffer as an example, I demonstrate why `#[repr(C)]` is essential for locking down memory layouts and how strategic padding prevents costly hardware coherence traffic.
Two cores writing to different fields that happen to share a 64-byte cache line will quietly serialize each other through the hardware coherence protocol - a pathology called false sharing.
- teo_zero
I don't get it. If the ring structure has 4 field (excluding the cold ones), and all 4 have alignment constraints, doesn't it define 4 zones in 4 cache lines, and not 2?
I expected head and cached_tail, for example, to share the same line, but since they are both 128-byte aligned, they end up in separate lines. Granted, both lines are dedicated to only one side of the producer-consumer pipe, but we're wasting cache lines for nothing.
- jauntywundrkind
Side note, nice seeing Debasish Ghosh working in Rust! Yay. As is tradition in Rust world, yes they have their own (rather extensive) repo of ring buffers. https://github.com/debasishg/ringmpsc-rs
- kouteiheika
> the mechanics that make zoning real: why #[repr(C)] is load-bearing, why the magic number is often 128 and not 64, and why adding prefetch hints can make things worse.
> The honest rule
Sigh... yet another Claude written article, and (unless I'm blind) it doesn't seem to be disclosed anywhere.
Normally I'm not the one to complain, but it's really tedious to see this writing style pretty much everywhere nowadays, and the more you see it the more you start to find it unbearable to read.