9 July 2025 · 3 min
The Apple M2, introduced in 2022, and the Apple M4, launched in 2024, are both ARM-based system-on-chip (SoC) designs featuring unified memory architecture. That is, they use the same memory for both graphics (GPU) and main computations (CPU). The M2 processor relies on LPDDR5 memory whereas the M4 relies on LPDDR5X which should provide slightly more bandwidth.
The exact bandwidth you get from an Apple system depends on your configuration. But I am interested in single-core random access performance. To measure this performance, I construct a large array of indexes. These indexes form a random loop: starting from any element, if you read its value, treat it as an index, move to this index and so forth, you will visit each and every element in the large array. This type of benchmark is often described as ‘pointer chasing’ since it simulates what happens when your software is filled with pointers to data structures which themselves are made of pointers, and so forth.
When loading any value from memory, there is a latency of many cycles. Thankfully, modern processors can sustain many such loads at the same time. How many depends on the processor but modern processors can sustain tens of memory requests at any given time. This phenomenon is part of what we call memory-level parallelism : the ability of the memory subsystem to sustain many tasks at once.
Thus we can split the pointer-chasing benchmark into lanes. Instead of starting at just one place, you can start at two locations at once, one at the ‘beginning’ and the other at the midpoint. And so forth. I refer the number of such divisions as a ‘lane’. So it is one lane, two lanes and so forth. Obviously, the more lanes you have, the faster you can go. From how fast you can go, you can estimate the effective bandwidth by assuming that each hit in the array is equivalent to loading a cache line (128 bytes). The array is made of over 33 million 64-bit words.
I run my benchmarks on two processors (Apple M2 and Apple M4). I have to limit the number of lanes since beyond a certain point, there is too much noise. A maximum of 28 lanes works well.
Maybe unsurprisingly, I find that the difference between the M4 and the M2 is not enormous (about 15%). Both processors can visibly sustain 28 lanes.
Daniel Lemire, "Memory-level parallelism : Apple M2 vs Apple M4," in Daniel Lemire's blog, July 9, 2025, https://lemire.me/blog/2025/07/09/memory-level-parallelism-apple-m2-vs-apple-m4/.
[BibTeX]
Do you think they can support more than 28 way memory level parallelism?
I am interested in what the noisier results with more than 28 lanes look like and why they might be noisy. Do you know?
My benchmark cannot answer this question. To go further, you probably want to write your own assembly and record the appropriate performance counters.
Whether you can, in actual code, sustain many more than 28 memory requests in flight is an open question… but I think it might prove difficult.
If you aren’t trying to thrash the TLB, why not randomly visit each cache line of a page before jumping to another page?
Under Linux, you can use large pages. It is less of a concern under these Apple systems due to their larger pages.
But we are not trying to measure the maximal bandwidth here… it would be easier done with sequential access.
I think it is a fair test.
Sure. I did the same thing, wanting to track down the cache miss through L1, L2, and L3, waiting on the memory controller, waiting through the contention for the right memory channel, and of course the return of the cache line all the way back to the CPU.
I just used pointer chasing with a sliding window so I’d get the same number of random cache lines, but not thrash the TLB. Using huge pages achieves very similar.
Complementary question: how many instructions are left over while doing this? If we saturate random reads, what percentage of cpu is available, and are any unexpected ports blocked?
My current benchmark does not allow me to answer your question.
Further, unfortunately, I do not have a good map of the Apple M4 architecture. I do not think Apple publishes any documentation. We do have some publicly available reverse engineering of the Apple M1, however.