Insurance thread

[AxolotlFever]

Hello!

I am making my engine multi-threaded, and I wonder if anyone has considered making one thread (out of say 4) run a much safer search ie no null move, for example.

This thread would then catch any tactical positions that escape our main thread, and would provide insurance on tactically charged situations.

Has anyone tried this, and does it sound like it could work? Possibly a mature engine might not benefit so much, but what about a more error-prone engine?

Best,
Louis

[jdart]

With no null move I think that thread will likely search to shallower depth.
So then you'd have a result with shallow depth but more accuracy (maybe) and one or more with more depth and less accuracy. Which to choose? I think most people would say, take the one with greater depth. So then your no null move thread wouldn't be used.
In practice, null move is a heuristic like most search enhancements. You are relying on it working most of the time although there are exceptions when it doesn't help. Accepting the occasional error tends to make the program stronger overall, over a series of games.
--Jon

[JVMerlino]

With no null move I think that thread will likely search to shallower depth.
So then you'd have a result with shallow depth but more accuracy (maybe) and one or more with more depth and less accuracy. Which to choose? I think most people would say, take the one with greater depth. So then your no null move thread wouldn't be used.
In practice, null move is a heuristic like most search enhancements. You are relying on it working most of the time although there are exceptions when it doesn't help. Accepting the occasional error tends to make the program stronger overall, over a series of games.
--Jon

Indeed. The overall gain of having another more CPU time on a search implementation that is known (assuming good implementation) to be stronger than a different (or less-featured) implementation is clear. It's a nice idea, but in practice it will lose ELO. The only similar idea that seems to work for some engines is having different threads working on different search depths simultaneously, and I think it is one that deserves further exploration.

[noobpwnftw]

I would guess the opposite might have some benefits, you can have a few threads with even more pruning so that they might reach higher depth and resolve bounds faster. One thing that I don't understand is that how can engines nowadays prune so aggressively and still get away with good results, but I can't fight the with the facts apparently.

[AxolotlFever]

ok thanks everyone, it did like a dubious idea...

With no null move I think that thread will likely search to shallower depth.
So then you'd have a result with shallow depth but more accuracy (maybe) and one or more with more depth and less accuracy. Which to choose? I think most people would say, take the one with greater depth. So then your no null move thread wouldn't be used.
In practice, null move is a heuristic like most search enhancements. You are relying on it working most of the time although there are exceptions when it doesn't help. Accepting the occasional error tends to make the program stronger overall, over a series of games.
--Jon

Quick question: you talk about "choosing" a result, but my understanding of lazy SMP is that you only really listen to the main thread - the others just populate the transposition table. Is this the standard way, or is this really *too* lazy?

Thanks!
Louis

[elcabesa]

Quick question: you talk about "choosing" a result, but my understanding of lazy SMP is that you only really listen to the main thread - the others just populate the transposition table. Is this the standard way, or is this really *too* lazy?

if you look at Stockfish code they have created a voting system for the threads where they vote the best move found based on score and depth of each thread

[JVMerlino]

Quick question: you talk about "choosing" a result, but my understanding of lazy SMP is that you only really listen to the main thread - the others just populate the transposition table. Is this the standard way, or is this really *too* lazy?

Thanks!
Louis

Well, Myrddin's implementation is about as lazy as possible, and that's what it does.

[Ratosh]

Pirarucu implements the "too lazy" smp and seems to scale really well.