stockfish threading model

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
Dann Corbit
Posts: 10187
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: stockfish threading model

Post by Dann Corbit » Fri May 13, 2016 4:08 pm

Dan Homan popularized the JaBOT (Just a Bunch Of Threads) model. The popular name is "Lazy SMP".

Lots of people are using it now.

It appears to work so well that nobody can explain the reason for its extreme success.

There is even an indication that it works better with hyperthreads turned on and all virtual cores busy in action. It defies the imagination. See Dmitri's posts on the topic.

An interesting trick some people are using is to have some threads starting a node or two forwards from the root if there are lots of threads.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

Michel
Posts: 2052
Joined: Sun Sep 28, 2008 11:50 pm

Re: stockfish threading model

Post by Michel » Fri May 13, 2016 7:12 pm

Dan Homan popularized the JaBOT (Just a Bunch Of Threads) model. The popular name is "Lazy SMP".
It was in fact Toga II that introduced this idea. From the rating lists it could be easily verified that Toga II scaled just as well as Stockfish which at that time had a rather sophisticated YBW implementation.
Ideas=science. Simplification=engineering.
Without ideas there is nothing to simplify.

Dann Corbit
Posts: 10187
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: stockfish threading model

Post by Dann Corbit » Fri May 13, 2016 7:25 pm

When was this introduced?
I would like to have a look at the first implementation
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

User avatar
cdani
Posts: 2104
Joined: Sat Jan 18, 2014 9:24 am
Location: Andorra
Contact:

Re: stockfish threading model

Post by cdani » Fri May 13, 2016 7:48 pm

flok wrote: I googled for more details, couldn't find them. But I wonder: is there more to it? Because a quick test showed no improvement here compared to a single threaded version of my program (also without locking in the tt). Also in the output I see each thread return the same pv with each thread contiously finishing an iteration at the same moment. I tried starting thread x at iteration level 1 + x (iteration level: search-depth) or even 1 + x * 2 but in both cases in only 1 or 2 maybe 3 steps they end up in that same-pv-same-depth situation.
Is possible there are some variables that are not well isolated one thread from the other? The only communication between threads should be the tt.

flok

Re: stockfish threading model

Post by flok » Fri May 13, 2016 8:02 pm

cdani wrote:
flok wrote: I googled for more details, couldn't find them. But I wonder: is there more to it? Because a quick test showed no improvement here compared to a single threaded version of my program (also without locking in the tt). Also in the output I see each thread return the same pv with each thread contiously finishing an iteration at the same moment. I tried starting thread x at iteration level 1 + x (iteration level: search-depth) or even 1 + x * 2 but in both cases in only 1 or 2 maybe 3 steps they end up in that same-pv-same-depth situation.
Is possible there are some variables that are not well isolated one thread from the other? The only communication between threads should be the tt.
Hmm I don't think so. If there would be, then it would be unprotected (eg no locking, barriers, etc) access (because only my tt implementation uses locks) and that would show up when I run things in helgrind (valgrind for threading).

User avatar
cdani
Posts: 2104
Joined: Sat Jan 18, 2014 9:24 am
Location: Andorra
Contact:

Re: stockfish threading model

Post by cdani » Fri May 13, 2016 8:09 pm

flok wrote: Hmm I don't think so. If there would be, then it would be unprotected (eg no locking, barriers, etc) access (because only my tt implementation uses locks) and that would show up when I run things in helgrind (valgrind for threading).
Don't think locking is that important or have noticeable effects. Andscacs shares tt and like 5 other small hashes like pawn hash between threads, and does nothing to prevent problems. No locking, no nothing. And all works nicely even at 31 threads.

Post Reply