Why does RandomX need so much cache?
RandomX needs so much cache because it repeatedly uses small pieces of working data in ways that are hard to predict. Cache is fast memory close to your CPU—the main processor in your device—and it helps keep mining from slowing down while the processor waits for data.
Why fast memory matters
RandomX is Monero’s mining algorithm: the set of calculations your device performs while trying to help add a block of transactions to the network. It has been in use since November 30, 2019.
Rather than repeat one simple calculation, RandomX runs programs that mix different operations and memory accesses. Your CPU must keep fetching data, changing it, and using the results in later steps.
Your device has several layers of memory:
- L1 cache: Very small and extremely fast, close to each processor core.
- L2 cache: Larger, but a little slower.
- L3 cache: Larger again, and often shared by several cores.
- RAM: Your computer’s main memory. It holds much more, but takes longer to access.
RandomX benefits from all these layers. Its unpredictable memory accesses make it harder for your processor to fetch everything ahead of time.
Where the 2 MB per thread comes from
Each RandomX mining thread—one separate stream of mining work—uses a 2 MB scratchpad. This is a temporary workspace that the algorithm reads from and writes to repeatedly.
Parts of that workspace are sized to benefit from L1 and L2 cache. The full scratchpad is intended to fit in L3 cache. That is why about 2 MB of available L3 cache per mining thread is an important planning rule.
For example, 16 MB of shared L3 cache gives you a rough starting point of eight mining threads. It does not guarantee that eight will be fastest. Your processor’s layout, other running software, and memory performance also matter.
You can run more threads than your cache comfortably supports. But their working data can push one another out of cache. The processor then spends more time waiting for slower memory, so extra threads may add little speed—or even reduce it.
The large dataset is a different kind of memory
The 2 MB scratchpad is not the same thing as RandomX’s much larger dataset.
In fast mode, RandomX uses a dataset of about 2,080 MB, normally held in RAM and shared by mining threads. It also has a separate 256 MB initialization cache used to build that dataset.
In light mode, it works from that 256 MB cache instead of keeping the full dataset in memory, calculating needed data along the way. This saves memory but is much slower for mining.
Here, “cache” means an algorithm data structure—not your CPU’s physical L3 cache. Having several gigabytes of free RAM therefore does not replace having enough L3 cache.
Why RandomX makes this trade-off
This memory-heavy design helps RandomX favor general-purpose CPUs over specialized mining chips.
A specialized chip cannot gain an easy advantage simply by packing in huge numbers of small calculation units. It also needs fast memory and the ability to handle varied instructions. Those features take chip space, power, and money.
That does not make specialized hardware impossible. It makes a large efficiency advantage harder to achieve.
The bottom line
RandomX needs substantial cache to keep each mining thread’s frequently changing workspace close to the CPU. For your device, more threads are not automatically better: enough cache per thread often matters more than using every available thread.
