Lazy SMP - how it works

[krismchess]

I have searched internet on how this works, but there is no proper documentation available - not even on the chess wiki. Is there a paper/documentation where Lazy SMP is explained?

Thanks in advance.

[kbhearn]

it's really really simple. exact implementation details vary. essentially all threads search on their own, only communicating via the hash table. some effort is usually done to get them out of sync earlier so they're doing different work like setting them to a variety of different depths to start.

And that's really all there is to it. What will or won't work in terms of details has to be tested, there is nothing to reason about because the search is so chaotic.

[jdart]

It is similar to ABDADA, which was published a long time ago.

See https://chessprogramming.wikispaces.com ... Lazy%20SMP.

--Jon

[krismchess]

It is similar to ABDADA, which was published a long time ago.

See https://chessprogramming.wikispaces.com ... Lazy%20SMP.

--Jon

Then what could be the specific differences between ABDADA vs. Lazy SMP.

It's frustrating why CPW doesn't have a page explaining Lazy SMP yet.

[Gerd Isenberg]

It is similar to ABDADA, which was published a long time ago.

See https://chessprogramming.wikispaces.com ... Lazy%20SMP.

--Jon

Then what could be the specific differences between ABDADA vs. Lazy SMP.

It's frustrating why CPW doesn't have a page explaining Lazy SMP yet.

I was too lazy so far to set up an own page ...

[Evert]

It is similar to ABDADA, which was published a long time ago.

See https://chessprogramming.wikispaces.com ... Lazy%20SMP.

--Jon

Then what could be the specific differences between ABDADA vs. Lazy SMP.

I don't think there is any specific difference. Shared hash table SMP pretty much describes what it is. The main "new" idea that I suppose could be mentioned is that you launch threads on different iteration depths (instead of at the same depth). Statistically, that leads to less overhead than depending on random timing fluctuations to desynchronise the threads.

It's frustrating why CPW doesn't have a page explaining Lazy SMP yet.

Well, it's a wiki. Anyone who feels that there's more that needs to be said about it is free to add it...

[flok]

Shared hash table SMP pretty much describes what it is. The main "new" idea that I suppose could be mentioned is that you launch threads on different iteration depths (instead of at the same depth). Statistically, that leads to less overhead than depending on random timing fluctuations to desynchronise the threads.

I tried:
- each thread with different max-depth (it. deep. depth)
- each thread starting with a different move at the root
but sofar after, say 9 plies the threads start to run in lock-step.

So I think there's something else that must be done, right? Maybe this only works with non-locking TTs?

[mar]

Maybe this only works with non-locking TTs?

Locks are cheap unless there's contention
If you have x threads constantly fighting for a single lock then performance-wise can be order of magnitude slower than serial.

What you can try to remedy this is to use n locks (say 256) and index them via 8 lsbits of entry/bucket index.

You can also try to avoid locks completely, I use Bob's xor-trick but AFAIK some engines don't bother at all,
all you need is robust validation of TT move.

[AlvaroBegue]

One difference between ABDADA and lazy SMP is that in ABDADA the hash entry keeps track of how many threads are working on it. I forgot exactly how that information was used (I read the paper many years ago), but it somehow discourages other threads from going down the same path.