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
Insurance thread
Moderators: hgm, Rebel, chrisw
-
- Posts: 50
- Joined: Sun Nov 11, 2018 9:26 pm
- Location: Germany
- Full name: Louis Mackenzie-Smith
Insurance thread
My chess engine is Axolotl: https://github.com/louism33/Axolotl
And it uses: https://github.com/louism33/
Othello/Reversi: https://github.com/louism33/Mudpuppy
And it uses: https://github.com/louism33/
Othello/Reversi: https://github.com/louism33/Mudpuppy
-
- Posts: 4367
- Joined: Fri Mar 10, 2006 5:23 am
- Location: http://www.arasanchess.org
Re: Insurance thread
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
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
-
- Posts: 1357
- Joined: Wed Mar 08, 2006 10:15 pm
- Location: San Francisco, California
Re: Insurance thread
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.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
-
- Posts: 560
- Joined: Sun Nov 08, 2015 11:10 pm
Re: Insurance thread
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.
-
- Posts: 50
- Joined: Sun Nov 11, 2018 9:26 pm
- Location: Germany
- Full name: Louis Mackenzie-Smith
Re: Insurance thread
ok thanks everyone, it did like a dubious idea...
Thanks!
Louis
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?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
Thanks!
Louis
My chess engine is Axolotl: https://github.com/louism33/Axolotl
And it uses: https://github.com/louism33/
Othello/Reversi: https://github.com/louism33/Mudpuppy
And it uses: https://github.com/louism33/
Othello/Reversi: https://github.com/louism33/Mudpuppy
-
- Posts: 855
- Joined: Sun May 23, 2010 1:32 pm
Re: Insurance thread
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 threadQuick 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?
-
- Posts: 1357
- Joined: Wed Mar 08, 2006 10:15 pm
- Location: San Francisco, California
Re: Insurance thread
Well, Myrddin's implementation is about as lazy as possible, and that's what it does.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
-
- Posts: 77
- Joined: Mon Apr 16, 2018 6:56 pm
Re: Insurance thread
Pirarucu implements the "too lazy" smp and seems to scale really well.