Re: back to the Komodo SMP issue
Posted: Fri Jul 05, 2013 6:12 pm
It has been spelled out quite a few times already and there is no use in Bob responding to it once more (although I know he will do it).duncan wrote:to avoid what bob will call handwaving perhaps you could spell it out or reference it if you have already done so, so bob can respond.syzygy wrote:Bob's argument is logically flawed in more than one way.
But since you are asking, I will respond for you (not for Bob).
The usual single-threaded search algorithms are inherently serial, which means it cannot be the same as the parallel search algorithm. The parallel search algorithm is inherently less efficient: an N-threaded search on N cores is not as effective as an 1-threaded search on an N times faster single core.
This inefficiency (and I am talking about common sense inefficiency and not about Bob's out-of-context textbook (in)efficiency), although unavoidable, is not fixed. It of course depends on the SMP implementation. It may also depend on the underlying single-threaded search.
Mimicking the single-threaded search as much as possible (so purely going for added depth) may, depending on these factors, be problematic.
It may be difficult or even impossible to take the same reduction/extension decisions as the single search would, so that it may turn out to be cheaper or even necessary to accept a wider search (at the cost of depth, but in return for higher quality at the same depth). If this is the case, then Bob's argument does not come into view: we would have loved to have the same selectivity as the default single threaded search, but it was simply not possible / too hard / too expensive to get right.
It may also be the case that the "SMP inefficiency" just happens to be significantly greater for the serial reduction/extension scheme of a particular engine than it is for a less agressive reduction scheme. Bob has stated multiple times that the speed up values from old papers don't anymore apply to today's highly selective searches. If a slightly less selective search has better SMP efficiency (in Bob's textbook sense) when going parallel than the default single-threaded selective search, then the gain in SMP efficiency may outweigh the loss due to lower selectivity. If this is the case, then Bob's argument clearly does not hold: going wider on a single core would only incur the loss of lower selectivity and not profit from better SMP efficiency, simply because there is no SMP on a single core.
What also must be kept in mind is that the development of a chess engine is full of trade-offs. It is safe to assume that Komodo's current SMP implementation is the best that Don could achieve in the time he had available for it. It might be that further improvements will allow him to go purely for depth (at the cost of an investment in development time). We have no way of knowing this, but one thing should be clear: nobody can ever be criticised for not yet achieving the optimal implementation.