How does L3 cache size determine the best XMRig thread count?

For Monero mining in XMRig, a good starting point is one mining thread for every 2 MB of usable L3 cache. Divide your CPU’s L3 cache by 2 MB, round down, and treat that result as a starting limit—not a guarantee of the fastest setting. Your CPU’s core count and how its cache is shared can lower the best thread count.

Why each thread needs cache space

XMRig is mining software that can run on your computer’s CPU, its main processor. Monero uses RandomX, a mining algorithm—the set of calculations your computer performs while mining.

Each RandomX mining thread, or separate stream of work, uses a roughly 2 MB working area called a scratchpad. L3 cache is a small, fast memory store built into your CPU. Keeping that working data close to the processor helps it avoid slower trips to your computer’s main memory, or RAM.

When too many threads compete for limited L3 space, they can push one another’s data out. Adding threads may then produce little extra speed, or even make mining slower.

Turn your L3 size into a starting count

Use this simple estimate:

Cache-based thread limit = L3 cache in MB ÷ 2, rounded down

For example:

• 8 MB L3: start by considering up to 4 mining threads.
• 16 MB L3: start by considering up to 8 threads.
• 32 MB L3: cache has room for roughly 16 threads.

Next, compare that number with your CPU’s physical cores, the actual processing units inside it. A CPU with 8 physical cores and 32 MB of L3 has enough cache for 16 mining threads, but that does not mean 16 will be fastest.

SMT, also called Hyper-Threading on many Intel CPUs, lets a physical core handle two software threads. Those threads still share core resources. Starting with one mining thread per physical core, within the cache limit, is usually sensible. Test extra threads rather than assuming they help.

Check how your CPU shares its cache

The total L3 number on a product page can hide an important detail: that cache may be split into separate groups.

For example, a CPU advertised with 32 MB of L3 might have two groups of cores, each sharing 16 MB. In that case, placing too many mining threads in one group can overload its cache while leaving the other group underused.

XMRig’s automatic settings normally provide a useful starting point because they consider the processor’s layout. If you adjust CPU affinity—which assigns threads to particular CPU cores—spread work across the available cache groups.

Also, do not confuse L3 with RandomX’s larger memory requirements. Its fast mode uses a 2,080 MB dataset in RAM; light mode uses a 256 MB cache. Neither replaces the per-thread L3 consideration.

Test the nearby settings

Run XMRig’s automatic configuration first, then compare a few thread counts around your cache-based estimate.

• Let each test run long enough for speed and temperature to settle.
• Compare hashrate, the number of mining calculations completed per second.
• Keep background activity similar between tests.
• Watch power use, heat, and how responsive your computer feels.

Other limits, including smaller CPU caches and memory speed, can change the result.

The bottom line

Use 2 MB of L3 per RandomX thread as your starting rule. Then account for physical cores and cache layout, and measure nearby settings. Your best count is the one that performs well on your CPU—not simply the largest number XMRig allows.