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 sam

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