Why does RandomX favor L3 cache so heavily?

RandomX favors L3 cache because each mining thread repeatedly works with about 2 MB of private working data, and keeping that data close to the processor avoids slow trips to main memory. A large, fast L3 cache lets more threads work efficiently at once, which is why extra CPU cores do not always mean faster Monero mining.

Why keeping data close matters

Your CPU, or processor, runs instructions using data stored in different places. Its cache is a small, fast storage area that keeps frequently needed data nearby.

Most desktop processors have several cache levels:

• L1 is very small and extremely fast.
• L2 is larger, but usually still too small to hold a thread’s full RandomX working area.
• L3 is larger again and is typically shared among several cores.
• RAM, your computer’s main memory, holds much more data but takes longer to access.

That waiting time is called latency. RandomX performs many operations that depend on data from earlier operations. When the processor is waiting for a needed value, it cannot simply finish the next calculation without it.

L3 matters because it offers enough space to hold useful working data while keeping access much faster than RAM.

Why RandomX needs roughly 2 MB per thread

Monero has used RandomX since November 30, 2019. Rather than repeating one simple calculation, RandomX runs generated programs that mix calculations, branches, and memory accesses. A branch is a choice about which instruction to run next.

Each mining thread, an independent stream of work, uses a scratchpad: about 2 MB of temporary working memory. RandomX accesses different parts of that scratchpad, with smaller working regions benefiting from L1 and L2.

The broader scratchpad accesses make L3 especially valuable. Many addresses depend on changing data, so the processor cannot reliably predict every access and fetch everything ahead of time.

This gives you the familiar guideline of roughly 2 MB of L3 cache per mining thread. It is a sizing rule for efficient mining, not a hard requirement that prevents RandomX from running with less cache.

Why more threads can make mining slower

Suppose your processor has 16 MB of usable L3 cache. Around eight mining threads would be a reasonable starting point for testing, because their scratchpads total about 16 MB.

That is not a guaranteed optimum. Your operating system and other programs also use cache. The processor may also divide its cache among groups of cores.

When too many threads compete for space, they push one another’s data out of cache. This is called cache eviction. Fetching that data again adds delays.

As a result, adding threads can:

• Produce little extra mining speed.
• Increase power use and heat.
• Sometimes reduce total speed.

L3 does not hold all of RandomX’s memory

The scratchpad is separate from RandomX’s larger shared data structures. Fast mode uses a 2,080 MB dataset, normally held in RAM. Light mode uses a 256 MB cache to calculate needed dataset items instead; that “cache” is a software data structure, not your CPU’s L3.

So L3 capacity alone cannot predict performance. RAM latency, processor design, and mining software matter too. Browser mining adds further software and memory constraints, so native-miner results may not match your browser’s results.

The bottom line

RandomX rewards L3 cache because it keeps each thread’s frequently accessed scratchpad close to the processor. Treat 2 MB per thread as a practical starting point, then test thread counts rather than assuming every available core should be mining.