Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multithreaded search. #30

Open
mateusz2173 opened this issue May 29, 2024 · 5 comments
Open

Multithreaded search. #30

mateusz2173 opened this issue May 29, 2024 · 5 comments
Labels

Comments

@mateusz2173
Copy link
Collaborator

We want to enable simple multithreaded search as follows:

  • Add engine option which can be set by setoption command like this: setoption name Threads value <int>
    which will set desired number of threads (1 by default)

Let's say N = number of threads

  • We run 1 main thread and N-1 additional threads
  • Both main and additional threads are running search on same position and same depth.
  • Both main and additional threads should use same, shared transposition table
  • Additional threads DO NOT output anything to stdout (they should not output any info or bestmove etc)
  • We ignore any output from additional threads.

The main reason we do that is additional threads will populate transposition table making main thread search quicker.

This is not ideal utilization of multiple threads but it is good enough for us for now.

@mateusz2173
Copy link
Collaborator Author

Should be done after #17 and #19

@DomiKoPL
Copy link
Collaborator

DomiKoPL commented May 29, 2024

Is this called Lazy SMP? https://www.chessprogramming.org/Lazy_SMP

@Gustav2137
Copy link
Collaborator

Lazy SMP has different depths for different threads.

@mateusz2173
Copy link
Collaborator Author

mateusz2173 commented May 29, 2024

It's almost the same.

LazySMP afaik runs from different depths to enforce more "randomness" in populating TT

We could have lazysmp immediately if anyone decides what I described in original post is too easy :P i believe lazysmp might be better from what I suggested

@DomiKoPL
Copy link
Collaborator

I'm fine with a simpler solution. It would be even better to actually implement it first and then benchmark how much we gained from "real" LazySMP

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants