Note that 'go depth N' first needs to be clearly defined in the context of SMP. There are various possible meanings.- all threads finished depth N- one thread finished depth N- one specific thread ('master') finished depth N
SF uses the last definition. Which means some other threads can have reached higher or lower depths, since the lazySMP implementation does not enforce any depth relationship between threads.Similarly, one has to agree on a definition of parallel efficiency. Natural for SF would be IMO: ' In a match of a threaded code with N threads, a sequential code with a factor M time-odds reaches the same score (0.5). In that case M/N is the parallel efficiency of that particular code, for that particular parallelization approach, under those testing conditions.'
On Sunday, January 5, 2020 at 5:45:59 PM UTC+1, joost.va...@gmail.com wrote:Note that 'go depth N' first needs to be clearly defined in the context of SMP. There are various possible meanings.- all threads finished depth N- one thread finished depth N- one specific thread ('master') finished depth NI think that the first definition is the only one that makes sense.
Anyway using the first definition there is still substantial Elo gain at fixed depth N. So yes it seems correct that SHT (Shared Hash Table) "widens" the search.Still I do not really understand this. I accept that the threads desynchronize and that the total tree is therefore wider. However ultimately we pick a move from a single thread. So for there to be an Elo gain in fixed depth search, the individual threads must widen. Do you see what might cause this?
- all threads finished depth N
I think that the first definition is the only one that makes sense.
Really depends on the purpose, and context. For example, you would like to keep threads idling till you satisfy definition 1 ? What about 'go mate N' ?
It won't matter that much anyway.
On Monday, 6 January 2020 09:11:07 UTC+1, michel.v...@uhasselt.be wrote:
On Sunday, January 5, 2020 at 5:45:59 PM UTC+1, joost.va...@gmail.com wrote:Note that 'go depth N' first needs to be clearly defined in the context of SMP. There are various possible meanings.- all threads finished depth N- one thread finished depth N- one specific thread ('master') finished depth NI think that the first definition is the only one that makes sense.Really depends on the purpose, and context. For example, you would like to keep threads idling till you satisfy definition 1 ? What about 'go mate N' ?
Anyway using the first definition there is still substantial Elo gain at fixed depth N. So yes it seems correct that SHT (Shared Hash Table) "widens" the search.Still I do not really understand this. I accept that the threads desynchronize and that the total tree is therefore wider. However ultimately we pick a move from a single thread. So for there to be an Elo gain in fixed depth search, the individual threads must widen. Do you see what might cause this?Guess that depends on the definition of 'widen'. I would argue that a single thread within the team has a search that is as narrow as (or actually even more narrow than) in the sequential case. However, through the shared hash table, it benefits from the (overall) wider search, e.g. it will have available a higher quality ttMove, or just be able to do a TT cutoff as that position might already have been searched more deeply by another thread as part of its search.
Guess that depends on the definition of 'widen'. I would argue that a single thread within the team has a search that is as narrow as (or actually even more narrow than) in the sequential case. However, through the shared hash table, it benefits from the (overall) wider search, e.g. it will have available a higher quality ttMove, or just be able to do a TT cutoff as that position might already have been searched more deeply by another thread as part of its search.Well maybe. But again it is not obvious to me why the ttMoves would be higher quality if they come from another thread executing a similar search algorithm. Of course ttMoves from other threads will speed up the search (more cutoffs etc...) but that alone does not help with a fixed depth search. And the Elo difference is really huge in the fixed depth case
Doesn't a second or more search return the value from the hashtable without searching further? It is the same depth so there should be a TT cutoff.
Interesting! So in each iteration stockfish is getting a different move order due to history/refutation etc and trying different LMR reductions for the same move.
It will then retain the score where the move is searched with the largest depth, through the hashtable, and thus effectively gettingrid of LMR from iteration to iteration .... Does this make sense ?
Also, single-threaded stockfish could potentially be improved by searching each depth twice or more ...
Remarkable was the very high draw rate of over 80 %, though.
Maybe there was something wrong in my setup, idk.
However, my first thought is there must be something basically wrong in Stockfish
if something like repating the same iteration is useful ...
A first quick test with a version that searches every iteration twice,
was much to my surprise still en par with master after 200 games, at tc 20+0.2.
This seems like a nice way to simulate SMP search, however.Especially on small devices with only a low number of threads available,one might get results comparable to a search with a higher number of threads.All you have to do is spend some more time, though. :-)
Might these interesting results of repeating same depth be related to artificially reducing main thread depth on fail highs?