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...
Evert wrote: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?
flok wrote: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.
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.