forked from official-stockfish/Stockfish
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
0 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
b5c8594
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of having helper threads that search at higher depth and are more aggressive in pruning.
Note that the skipSize is not linear in idx, but that might not be needed.
b5c8594
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Joost. You know from what I got the idea? I think since months of a way to implement Monte Carlo search in Stockfish, and then I thought the Lazy SMP is somewhat connected to that, and I think of this idea as a way of enhancing the Monte Carlo search for SF.
b5c8594
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Stefano80 I'm really sorry... hit the stop button in the wrong tab (wanted to terminate my own run)!
b5c8594
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't worry, no harm done.
b5c8594
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hope this does well! Seems like 7 threads might be a more convincing test. Maybe for LTC?
b5c8594
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Stefano80
Hi Stefano,
Strangely enough I am currently working on implementing Monte-Carlo for Stockfish too.
My branch for this is there, it is very preliminary for the moment: https://github.com/snicolet/Stockfish/tree/montecarlo
I would be interested in sharing ideas and implementations details, do you have a working branch?
Maybe we could make a league of the three Stefans on this subject with @locutus2 , I think he would probably be interested too :-)
Stéphane
b5c8594
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool, good luck!
b5c8594
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Stefano80
I have set for your 15 core the the troughput back to 1000. There are only 5 machines which have 15 >= cores so a low throughput makes not sense.
@snicolet
I thinked too about Monte-Carlo for chess but have not enough time to really try something in this direction.
A pure Monte-Carlo approach seems not promising because of the high tactical nature of chess but perhaps mixture with classic search. Search up to a certain depth (or some other condition like a quiet position) with PVS and then further with Monte-Carlo.
b5c8594
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Stefano80
Looking at this your sentence and the content or your patch, it seems you assume that threads with higher idx are usually searching at higher depths than threads with lower idx. From my experience this is'nt necessarily the case. 2 Years ago I made some debugging with the current skipping scheme and I did'nt observe such behaviour. I think therefore your patch might need an additional condition: use more aggressive in pruning at higher threads if the current search depth is ahead to most (or all) others. Without this additional condition I fear that the higher threads override tt-entries with less quality than the lower threads which is harmful. But if the high-thread is processing also the highest search-depth so far, then this should be harmless and could effectively help to finish the iteration faster. Just my toughts on this. GL with your experiments.
b5c8594
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Günther, I actually am convinced in the meantime that I just had luck in the first attempt. What would you think of the idea of pruning more only in the case that I have not a ttmove? So I would reduce the chance of overwriting a good quality entry.
b5c8594
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Stefano,
i'm skeptical about the ttmove condition because there are several reasons for not getting any ttmove:
IMO just in case 3 we can apply more aggressive pruning without taking to much risk.
What I intended to propose in my last post, was to track maxCompleted depth over all threads and apply more aggressive pruning just on those threads which are searching at rootDepth above maxCompleted
b5c8594
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will give it a try tonight