DTS-ification of YBWC

[bob]

When you run on 16 or 32 cores, the idle time begins to add up.

I have no experience of these systems, so you are likely right here. When these machines become more common we will pay more attention to SMP-code and consider switching to DTS. With Quad or Octa it seems that simple YBW is more than sufficient.

(1) Crafty doesn't split until the YBWC is satisfied. This can leave processors idle, since this is tested at the current node only, and at each succeeding node so long as idle processors exist. DTS can split anywhere, anytime, so that this idle time does not accumulate.

(2) DTS gives you a chance to find a _much better_ split point. I'd always prefer splitting close to the root if YBWC is satisfied there, or even at the root as I do in Crafty. But I can't split there until I back up in the search to get there. Which means that since I spend most of the time deep in the tree, I have to split at points where there is not a lot of work to do. I limit this by not splitting too near the end of the normal search, but this then increases the effect covered in (1) above. So in Crafty I end up doing a lot of splits, deep in the tree, where the split overhead becomes a significant cost. At the root, there is almost zero cost. DTS can split at the root even if the current node is at ply=20, which is a plus.

This becomes more important as more cores are used. When I make these kinds of changes (and I do modify this code from time to time) I can test it on our 70 node x 8 core cluster to see if it plays better than the old version, which high accuracy. So I don't have to "guess" whether it helps or not. A 10% speedup is not going to be 10 Elo. So it takes a ton of games so measure such. Also slower games are different than faster games when dealing with SMP issues, so long games are also important.

Agreed.

I begin to see issues on 8 cores, but not like 16, 32 or 64...