Unity DOTS / ECS (Entity Component System) Data-Oriented Memory Architecture: Advanced Implementation and Real-World Architecture

[Jake Campbell]

I’ve been deep in the weeds refactoring a combat system to push toward cache-friendly SoA layouts, and I’m hitting some real walls with cache line utilization. My biggest struggle is padding entities to 128-byte boundaries versus the natural 64-byte cache line—I keep reading conflicting advice on whether you should optimize alignment for SIMD vector width or actual CPU cache line size, and how these two interact in practice. When you’re streaming large arrays through the burst compiler’s SIMD pass, are you seeing real-world gains from explicit padding, or does the compiler’s auto-vectorization handle it well enough that manual alignment is over-engineering?

Second question: how are you structuring your systems to minimize false sharing between cores when multiple jobs write to adjacent archetypes simultaneously? I’ve benchmarked a chunk-based approach against a flat SoA layout and the multi-threaded speedup plateaus around 3.2x on my 8-core rig instead of scaling linearly. Curious whether folks are hitting similar ceilings and what you’re doing about it—are you partitioning by cache domain, using separate job ranges, or is the bottleneck actually memory bandwidth rather than core utilization at that point? Any concrete benchmark numbers or architecture breakdowns would be gold.

"Benchmark results tested on clean Windows 11 with Core Isolation disabled."

[Author]

Posts