How much L3 cache do I need per thread for RandomX?
For Monero’s RandomX mining, plan for 2 MB of L3 cache per mining thread. To estimate a sensible thread count, divide your processor’s available L3 cache by 2 MB, then test nearby settings to see which runs best on your PC or server.
What the 2 MB rule means
L3 cache is a small, fast memory area inside your processor, usually shared by several processor cores. It helps your processor avoid waiting for data from your much slower main memory, or RAM.
A mining thread is one stream of mining work running on your processor. RandomX gives each thread a working memory area called a scratchpad, which is about 2 MB. Having enough L3 cache for those scratchpads helps mining run efficiently.
For example:
- 8 MB of available L3: start with up to 4 mining threads.
- 16 MB of available L3: start with up to 8 mining threads.
- 32 MB of available L3: start with up to 16 mining threads.
These are starting points, not promises of performance. Your processor also needs enough execution resources—the parts that actually do the calculations—to make those threads useful.
Why more threads can make mining slower
Your operating system may show more logical processors than your CPU has physical cores. Features such as Hyper-Threading let one physical core handle two threads, but they do not double its L3 cache.
Suppose your processor has 8 physical cores, 16 logical processors, and 16 MB of L3. Starting with 8 mining threads makes sense. Running 16 mining threads would mean their scratchpads need about 32 MB, beyond that processor’s L3 capacity.
Mining can still run when you exceed the cache guideline. The problem is that threads compete for cache space and may need more trips to RAM. You could get:
- Little or no extra mining speed.
- Lower total mining speed.
- More power use and heat.
- Less responsive everyday applications.
The goal is not to keep every logical processor busy. It is to get useful mining work from the power your machine uses.
On servers, check how the cache is shared
A processor’s advertised L3 total does not always act like one equally accessible pool. Some processors split their cores and cache into groups. Servers with multiple processor sockets also have separate cache resources for each processor.
For example, two processors with 16 MB of L3 each are best treated as two separate 8-thread starting budgets—not one unrestricted 32 MB pool.
Where the mining threads run matters. Native mining software may let you use thread affinity, which means assigning threads to particular cores. Spreading threads across the appropriate cache groups can help avoid crowding one group while leaving another underused.
Cache is separate from RAM
The 2 MB-per-thread guideline does not replace RandomX’s main-memory needs. Fast mode uses a 2,080 MB dataset, a large collection of data used during mining. Light mode uses a 256 MB cache in RAM and is substantially slower. That RAM cache is different from your processor’s L3 cache.
In a browser, you may have less control over thread placement and memory use. Start conservatively and compare mining speed, power use, and responsiveness rather than assuming the cache calculation guarantees a result.
The bottom line
Budget 2 MB of L3 per RandomX mining thread. Treat that as a practical starting rule, account for separate cache groups on larger systems, and test nearby thread counts before choosing your setting.
