Page 1 of 1
Insurance thread
Posted: Thu Dec 20, 2018 2:44 pm
by 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
Re: Insurance thread
Posted: Thu Dec 20, 2018 3:52 pm
by 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
Re: Insurance thread
Posted: Thu Dec 20, 2018 5:34 pm
by JVMerlino
jdart wrote: ↑Thu Dec 20, 2018 3:52 pm
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.
Re: Insurance thread
Posted: Thu Dec 20, 2018 5:43 pm
by 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.
Re: Insurance thread
Posted: Thu Dec 20, 2018 6:52 pm
by AxolotlFever
ok thanks everyone, it did like a dubious idea...
jdart wrote: ↑Thu Dec 20, 2018 3:52 pm
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
Re: Insurance thread
Posted: Thu Dec 20, 2018 8:18 pm
by 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
Re: Insurance thread
Posted: Fri Dec 21, 2018 12:24 am
by JVMerlino
AxolotlFever wrote: ↑Thu Dec 20, 2018 6:52 pm
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.
Re: Insurance thread
Posted: Fri Dec 21, 2018 12:50 am
by Ratosh
Pirarucu implements the "too lazy" smp and seems to scale really well.