Hash, Threads And Multi-PV: The Three Settings That Matter

Open Stockfish’s options dialog in any GUI and you get a wall of controls. Contempt (on older builds), Move Overhead, Slow Mover, UCI_LimitStrength, Skill Level, Ponder, SyzygyPath, nodestime, EvalFile. For a 1400-rated player trying to work out why they lost a rook ending, roughly all of it is noise. Three settings change what you actually see on screen: Hash, Threads, and MultiPV. Everything else either does nothing at analysis time or actively makes your engine worse at telling you the truth.

That is the whole claim of this post. Set three numbers correctly, leave the rest alone forever, and your analysis output goes from “a number that scrolls past” to something you can interrogate.

Hash: the engine’s short-term memory

Stockfish’s search visits the same position via different move orders constantly. 1.e4 e5 2.Nf3 Nc6 3.Bb5 and 1.e4 Nc6 2.Nf3 e5 3.Bb5 are the same board. The transposition table is where Stockfish caches “I already searched this, here’s what I found,” and Hash is how many megabytes that table gets.

Default in most GUIs is 16 MB. Sixteen. Your laptop has sixteen thousand. At 16 MB and a modern CPU pushing 2-3 million nodes per second, you fill the table in about five seconds of thinking, after which Stockfish starts throwing away good work to make room for new work. On a quiet middlegame position you might notice nothing. In a closed Ruy Lopez or a queen-and-pawn ending where the tree transposes constantly, a starved table costs you real depth.

Here is the rule that actually matters: give Stockfish half your free RAM, rounded down to a power of two. Not half your total RAM, half of what isn’t already spoken for by Chrome and Slack and the GUI itself.

Powers of two aren’t superstition. Stockfish’s table is indexed by bit-masking the position hash, so 3000 MB gets used as if it were 2048 MB. You’d be paying for a gigabyte of RAM that sits there doing nothing.

The failure mode on the other side is nastier than most people expect. Set Hash to 24 GB on a 16 GB machine and your OS starts swapping the transposition table to disk. Stockfish doesn’t crash or warn you. It just slows to a crawl, sometimes by a factor of fifty, while the node counter crawls and you sit there wondering why depth 30 is taking four minutes. If your analysis suddenly feels like wading through treacle, Hash is the first thing to check.

One habit worth building: clear the hash between unrelated positions. Most GUIs have a “Clear Hash” button or do it automatically on new game. Carrying over a table full of entries from a totally different structure doesn’t corrupt anything, but it wastes space you paid for.

Threads: more cores, less certainty

Threads tells Stockfish how many CPU cores to search with. Default is 1. If you have an 8-core machine and you’re analysing at one thread, you’re using 12% of your hardware.

The rule: physical cores minus one. Leave a core for the GUI and the operating system, or your interface stutters and the engine’s own timing gets noisy.

Find your physical core count properly. On Windows, open Task Manager, go to Performance, click CPU, and read “Cores” (not “Logical processors”). On a Mac, run sysctl -n hw.physicalcpu in Terminal. On Linux, lscpu | grep "^Core(s)" and multiply by sockets.

The hyperthreading question comes up constantly. An 8-core Intel chip reports 16 logical processors. Should you set Threads to 15? For analysis, generally no. Stockfish gains maybe 10-15% from hyperthreads while making your machine unresponsive and heating your laptop into thermal throttling, which then costs you more than 15%. Set it to 7 and forget it. On a desktop with good cooling you can experiment upward, but check that your node rate genuinely scales: if going from 8 to 15 threads moves you from 12 Mn/s to 13 Mn/s, you’ve bought noise.

Now the part nobody tells improvers. Multi-threaded search is non-deterministic. Run the same position twice at 4 threads and you will get slightly different evaluations, sometimes different best moves. The threads share a hash table and race each other; whichever finishes a subtree first shapes what the others see. This is normal and not a bug.

It has a practical consequence. If you’re testing whether 15…Nd7 or 15…Nb6 is better and the engine says +0.31 versus +0.28, that gap is inside the noise floor. You have not learned anything. Either let it run much deeper, or accept that the two moves are equal and pick by structure. Anything under about 0.30 at moderate depth is a coin flip dressed up as a number.

A useful check on your setup:

Threads 1:   info depth 24 seldepth 33 nodes 18234109 nps 1721043
Threads 7:   info depth 24 seldepth 35 nodes 94012883 nps 9840219

That’s roughly 5.7x the node rate from 7x the cores, which is about right. Parallel search has overhead; you never get linear scaling. If you set 7 threads and see only 2x, something else on your machine is eating CPU, or you’re on a laptop that’s throttling.

MultiPV: the setting that changes how you learn

Hash and Threads make Stockfish faster. MultiPV changes what it tells you, and for an improver it is the single most valuable option in the dialog.

By default, MultiPV is 1. The engine reports one line: the best move and the principal variation after it. That is what a computer wants. It is not what a student wants, because it answers a question you didn’t ask. You played 22.Rfe1 and the engine says 22.Nd5 is best at +1.4. Fine. But what you need to know is: how bad was 22.Rfe1? Was it the second-best move, a hair behind? Or the eleventh?

Set MultiPV to 3 or 4 and the output becomes a ranking:

 1. +1.42  22. Nd5 exd5 23. exd5 Ne7 24. d6 Nc6 25. Qf3
 2. +1.31  22. Rfe1 Qc7 23. Nd5 exd5 24. exd5 Nb8
 3. +0.44  22. Bxf6 Bxf6 23. Nd5 Bg7 24. Nxb6 axb6
 4. +0.12  22. Qd2 Rfd8 23. Rad1 Bf8

Suddenly you know something real. Your move was second-best and cost 0.11, which at club level is nothing. The engine’s preference is a move-order refinement, not a lesson. Meanwhile there’s a genuine fork in the road at line 3 versus line 1: trading on f6 throws away most of the advantage. That’s the actual content of the position, and MultiPV 1 would have hidden it behind a single confident number.

The reverse case is where it gets sharper. If lines 1 through 4 read +2.1, +0.2, +0.1, -0.3, you’re looking at a position with exactly one move. Those are the positions worth drilling. Write the position down, come back in a week, see if you find it.

Cost: MultiPV isn’t free. The engine can no longer prune lines that fall below the best move’s window, because it has to evaluate them properly to rank them. Expect to lose 2-4 ply of depth at MultiPV 3 compared to MultiPV 1 for the same time. That trade is almost always worth it during review. Set it back to 1 when you want maximum depth on one critical position.

My recommendation by task:

• Reviewing your own games: MultiPV 3. You want to know where your move sat in the ranking.
• Building an opening repertoire: MultiPV 4 or 5. Playable alternatives matter more than the single top choice, especially if the top choice requires memorising 14 moves of theory.
• Solving a tactical position or checking a critical endgame: MultiPV 1. Depth is everything.
• Understanding a strategic position where nothing forcing exists: MultiPV 4, then ignore the evaluations and read the moves. Four engine lines that all play on the queenside tell you where the play is.

Putting the three together

A worked setup for the most common machine I see, a 16 GB laptop with a 6-core CPU:

Hash      4096
Threads   5
MultiPV   3

Three numbers. That configuration will search a middlegame position to depth 30-ish in under a minute, show you three ranked candidate moves, and leave your browser usable.

And a second one, an 8 GB older machine with 4 cores:

Hash      1024
Threads   3
MultiPV   3

Slower, obviously. Depth 26 instead of 32. Here’s the thing: for positions from your own games, depth 26 with three lines is more instructive than depth 35 with one. The extra depth mostly refines evaluations in positions you’d never reach. The extra lines tell you whether the move you played was reasonable. If your hardware is the limiting factor and you want deeper numbers on genuinely sharp positions, cloud engines and Lichess’s shared analysis cache are covered in our guide to engine setup, GUIs and cloud depth.

What to leave alone, briefly

Since the angle here is that everything else is noise, a short accounting of why. Skill Level and UCI_LimitStrength deliberately weaken the engine by making it choose worse moves. For sparring, sure. For analysis, you’re asking a handicapped engine for the truth. Move Overhead and Slow Mover only affect time management during games, not infinite analysis. Ponder matters only when the engine plays against you. Contempt was removed from Stockfish years ago and any guide still telling you to tune it was written before 2021. Syzygy tablebases are genuinely useful, but only in positions with seven or fewer pieces, and by then Stockfish’s search usually finds the truth anyway.

The one exception worth a footnote: if you’re on a machine with a CPU older than about 2013, check which Stockfish binary you downloaded. The modern NNUE evaluation wants AVX2 instructions. Running an AVX2 build on a chip that lacks it fails loudly; running the fallback build on a modern chip costs you maybe 30% speed silently.

Go and set your three numbers now, then load the last game you lost. Set MultiPV to 3, find the move where your evaluation swung by more than a pawn, and look at what the second and third lines were doing. That gap between “the engine’s move” and “the moves that were also fine” is where most of the learning lives, and you have been invisible to it every time you left MultiPV at 1.