Skip to content

Commit

Permalink
Cosmetics
Browse files Browse the repository at this point in the history
  • Loading branch information
@Stefano80
Stefano80 committed Nov 12, 2017
1 parent 4938223 commit b5c8594
Showing 1 changed file with 0 additions and 1 deletion.
1 change: 0 additions & 1 deletion src/thread.cpp
View file
Expand Up @@ -114,7 +114,6 @@ int Thread::reductions() {
return 1000*idx;
}


/// ThreadPool::init() creates and launches the threads that will go
/// immediately to sleep in idle_loop. We cannot use the constructor because
/// Threads is a static object and we need a fully initialized engine at
Expand Down

12 comments on commit b5c8594

@vondele
Copy link

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.

@Stefano80
Copy link
Owner Author

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.

@vondele
Copy link

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)!

@Stefano80
Copy link
Owner Author

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.

@mstembera
Copy link

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?

@snicolet
Copy link

@snicolet snicolet commented on b5c8594 Nov 13, 2017 •
edited

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

@vondele
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool, good luck!

@locutus2
Copy link

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.

@pb00068
Copy link

@pb00068 pb00068 commented on b5c8594 Nov 13, 2017 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Stefano80

Reduce more higher threads (and help them finish their higher depths).

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.

@Stefano80
Copy link
Owner Author

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.

@pb00068
Copy link

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:

  1. chronic all-node
  2. no tt-hit because entry was overridden by another position (hash pressure)
  3. no tt-hit because we are cruising new territory

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

@Stefano80
Copy link
Owner Author

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

Please sign in to comment.