Why does RandomX need 2MB of L3 cache per thread?
RandomX uses a 2 MiB working area for each mining thread, so having roughly that much L3 cache per thread helps your CPU mine efficiently. It is a performance guideline, not a hard requirement: you can mine with less cache, but your processor may spend more time waiting for data.
What each mining thread needs
A thread is one stream of work running on your CPU, your computer’s main processor. Each RandomX mining thread uses its own scratchpad: a temporary area of memory where it repeatedly reads and changes data while doing mining calculations.
That scratchpad is 2 MiB in size. Hardware discussions often call this “2 MB,” although MiB is the more precise unit: 2 MiB is 2,097,152 bytes.
RandomX accesses different parts of the scratchpad at different frequencies. Smaller, frequently used regions benefit from the CPU’s smaller, faster caches. The full scratchpad benefits from L3 cache, a larger pool of fast memory built into the processor.
On many CPUs, several cores share that L3 cache. Adding mining threads therefore increases the amount of scratchpad data competing for the same space.
Why cache makes such a difference
Your CPU can usually retrieve data from its cache much faster than from RAM, your computer’s main working memory.
RandomX runs changing sequences of instructions and makes many memory accesses whose locations depend on earlier calculations. That makes it harder for the processor to fetch every piece of data ahead of time.
When the needed data is already in cache, the CPU can keep working. When it is not, a cache miss occurs: the processor must retrieve it from a slower memory level.
With too many threads, their scratchpads can push one another’s data out of L3. The result can be:
- More waiting for memory.
- Less work completed by each thread.
- Little extra mining speed, or even a slowdown, when you add threads.
This memory-heavy design also helps RandomX favor general-purpose CPUs over simpler hardware designed only to perform repetitive calculations. The scratchpad is one part of that design, not the entire explanation.
How to use the 2 MiB guideline
As a starting point, divide your available L3 cache by 2 MiB.
For example, 16 MiB of L3 suggests trying about eight mining threads. That does not guarantee eight is the best setting. Your operating system and other programs also use cache, and the processor’s layout matters.
Some CPUs divide L3 into separate groups. On a server with multiple processors, cache on one processor is not simply a shared pool available equally to every thread.
Test nearby thread counts and compare your hashrate, the number of mining calculations completed per second. Also watch power use and responsiveness.
Do not confuse this scratchpad with RandomX’s other memory needs. Its fast mode uses a roughly 2,080 MiB dataset, which threads can share. Its light mode uses a 256 MiB cache—a software data structure, not the CPU’s physical L3 cache. Neither replaces each thread’s scratchpad.
The bottom line
RandomX does not demand exactly 2 MiB of physical L3 for every thread to run. That guideline comes from the size of each thread’s scratchpad. Enough nearby cache reduces slow memory accesses, so choosing a sensible thread count can matter more than running every thread your CPU supports.
