

Game Performance: Data-Oriented Programming - ingve
http://android-developers.blogspot.com/2015/07/game-performance-data-oriented.html

======
vardump
Yup. When performance matters, don't chase pointers (references) and don't
ever do random memory accesses if you can avoid it. Ensure variables needed
about same time are near each other, so that a single cache line fill will get
all. Except when other threads/cores frequently update a variable, try to keep
those separately to reduce false sharing.

Remember you _typically_ have just 512 L1 data cache lines to work with. Up to
1024, some CPUs might have just 256. Wrong data access patterns will
continuously invalidate those.

Imagine processing an image stored in row-major format and reading pixels
vertically. If the image is taller than 512 pixels and wider than 64 bytes,
you're pretty much guaranteed to have continuous L1D cache misses. So swizzle
[1] or at least divide image in smaller blocks first to improve L1D cache hit
rate.

On top of that using SIMD is pretty beneficial.

Small nitpick: pretty much all of the CPU cores I can think of (representing
99% of cases, I think) have 64 byte cache lines, not 16 like this article
suggests. The remaining have 32 byte cache lines. While they might exist, I
don't know any modern CPU with 16 byte cache lines.

[1]: One common swizzling curve/algorithm:
[https://en.wikipedia.org/wiki/Z-order_curve](https://en.wikipedia.org/wiki/Z-order_curve)

