Insurance thread

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
AxolotlFever
Posts: 39
Joined: Sun Nov 11, 2018 8:26 pm
Location: Germany
Full name: Louis Mackenzie-Smith
Contact:

Insurance thread

Post by AxolotlFever » Thu Dec 20, 2018 1:44 pm

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
Posts: 3719
Joined: Fri Mar 10, 2006 4:23 am
Location: http://www.arasanchess.org

Re: Insurance thread

Post by jdart » Thu Dec 20, 2018 2: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

User avatar
JVMerlino
Posts: 983
Joined: Wed Mar 08, 2006 9:15 pm
Location: San Francisco, California

Re: Insurance thread

Post by JVMerlino » Thu Dec 20, 2018 4:34 pm

jdart wrote:
Thu Dec 20, 2018 2: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.

noobpwnftw
Posts: 288
Joined: Sun Nov 08, 2015 10:10 pm

Re: Insurance thread

Post by noobpwnftw » Thu Dec 20, 2018 4:43 pm

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
Posts: 39
Joined: Sun Nov 11, 2018 8:26 pm
Location: Germany
Full name: Louis Mackenzie-Smith
Contact:

Re: Insurance thread

Post by AxolotlFever » Thu Dec 20, 2018 5:52 pm

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

jdart wrote:
Thu Dec 20, 2018 2: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

elcabesa
Posts: 794
Joined: Sun May 23, 2010 11:32 am
Contact:

Re: Insurance thread

Post by elcabesa » Thu Dec 20, 2018 7:18 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?
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

User avatar
JVMerlino
Posts: 983
Joined: Wed Mar 08, 2006 9:15 pm
Location: San Francisco, California

Re: Insurance thread

Post by JVMerlino » Thu Dec 20, 2018 11:24 pm

AxolotlFever wrote:
Thu Dec 20, 2018 5: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. :D

Ratosh
Posts: 61
Joined: Mon Apr 16, 2018 4:56 pm

Re: Insurance thread

Post by Ratosh » Thu Dec 20, 2018 11:50 pm

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

Post Reply