The 56-Byte Mistake That Makes Code Run 13× Slower on Intel
What CPU Cache Really Reveals About Intel vs AMD Performance (Part 2)
Cache Boundaries, Parallelism, and the Multithreading Disaster
In Part 1, we established the foundation: the 100× gap between L1 cache and RAM, the measurement methodology (RDTSC with isolated cores), and the first two tests showing memory dominance and pure latency measurement. Now we dive into the most dramatic findings.
Quick recap from Part 1:
Memory latency has gotten worse over 20 years (15ns → 100ns) while CPUs got faster
Test 1 showed memory access patterns dominate everything (300 cycles vs 1 cycle for arithmetic)
Test 2’s pointer chasing revealed pure memory latency: Intel at 1.49 cycles/elem, AMD at 1.57
Both tests proved the compiler preserved our access patterns (assembly verification)
Now let’s explore what happens when data grows too large for cache, when CPUs try to parallelize instructions, and when threads fight over shared cache lines.
Test 3: The Cliff Edge
The most dramatic test: what happens as your data grows from tiny (fits in L1) to massive (forces main RAM access)?
The test is elegantly simple—scan an array with 64-byte strides (exactly one cache line):
By touching one byte every 64 bytes, we’re measuring the cost of fetching cache lines without additional spatial locality benefits. The stride is constant—only the data size changes, from 1 KB to 64 MB.
Here’s the critical setup detail:
We’re measuring cycles per cache line access. As the array grows, it transitions through each cache level. Here’s where we see the cache hierarchy laid bare:
