Hi Tom,
Many thanks for the write up!
I followed your ideas and implemented simplified ABDADA in Barbarossa (up to step 6, but without cutoff checks yet). I skipped some of the preparation steps which were meant basically to make sure the implementation is correct so far.
In my own tests I got ~80 Elo for 2 cores, which is in accordance with the theory. Not sure how it scales further, I will need more tests.
The multi threading Barbarossa will be used in next HGM tournament.
There were some technical complications with:
- LMR: when I defer a move, it will be played at the end with the "later" reduction (not sure if this is correct)
- re-search (because I use PVS): I think you already stated that in this case the "currently searching" of that move should be deleted, so that other threads eventually help with the re-search: I implemented this idea, but I'm not sure if it is quite correct or if it has any effect without synchronization between threads
"Simplified ABDADA" updated
Moderators: hgm, Rebel, chrisw
-
- Posts: 175
- Joined: Fri Oct 22, 2010 9:47 pm
- Location: Austria
-
- Posts: 64
- Joined: Fri Jul 03, 2015 9:22 pm
Re: "Simplified ABDADA" updated
That's great! I'm glad it's working well and that you (presumably) found it useful!nionita wrote:Hi Tom,
Many thanks for the write up!
I followed your ideas and implemented simplified ABDADA in Barbarossa (up to step 6, but without cutoff checks yet). I skipped some of the preparation steps which were meant basically to make sure the implementation is correct so far.
In my own tests I got ~80 Elo for 2 cores, which is in accordance with the theory. Not sure how it scales further, I will need more tests.
The multi threading Barbarossa will be used in next HGM tournament.
I haven't tried LMR (I know, I know) but I suspect this isn't correct. What you could do is, as you're deferring the move, record the depth that you WOULD have searched the move at.There were some technical complications with:
- LMR: when I defer a move, it will be played at the end with the "later" reduction (not sure if this is correct)
Here's the rationale: when you mark a move as currently being searched, the theoretical idea is that you're dividing up work between threads, but the PRACTICAL effect of doing that is to make other threads search that move later.- re-search (because I use PVS): I think you already stated that in this case the "currently searching" of that move should be deleted, so that other threads eventually help with the re-search: I implemented this idea, but I'm not sure if it is quite correct or if it has any effect without synchronization between threads
When you're re-searching a move because of a null-window failure, that means the move is very likely to fail high or at least change alpha, so that's important search information that every thread should ideally know before searching any subsequent move. So the last thing you want your threads to do is skip over the move that's failing. So that's why it shouldn't be marked as currently being searched.
So that's the theoretical explanation. In practice, the benefit is small but measurable with my chess engine. Hope this helps!
-
- Posts: 175
- Joined: Fri Oct 22, 2010 9:47 pm
- Location: Austria
Re: "Simplified ABDADA" updated
Ok, I will have to try this. I was thinking that, when you defer a move, chances are high that when you come to search it, there is a TT entry for it, and that should have the correct depth anyway, as it was searched in the same position, but not deferred.TomKerrigan wrote:I haven't tried LMR (I know, I know) but I suspect this isn't correct. What you could do is, as you're deferring the move, record the depth that you WOULD have searched the move at.
But of course if the search in the first thread was not finished at that time then this is not the case. It is hard to understand all implications of this concurrent search... I guess best approach is to try both variants and take the best.
-
- Posts: 1
- Joined: Thu Dec 07, 2017 9:44 pm
- Location: France
Re: "Simplified ABDADA" updated
Thanks for enhancing this old parallel search! I hope you find it usefull.
(jcw)
-
- Posts: 64
- Joined: Fri Jul 03, 2015 9:22 pm
Re: "Simplified ABDADA" updated
Great to hear from you and thank you so much for developing the original algorithm!jcw66 wrote:Thanks for enhancing this old parallel search! I hope you find it usefull.
I think almost anything that's self-synchronizing is terrific. Self-synchronizing Young Brothers Wait is a stroke of genius.