Author: Stuart Cracraft
Date: 15:29:40 01/20/98
Go up one level in this thread
On January 20, 1998 at 17:33:15, Carsten Kossendey wrote: >On January 20, 1998 at 17:13:06, Bruce Moreland wrote: > >>I think that I should admit that I didn't understand your original post >>and I don't understand the source code you provided later. I don't know >>why "quiescence" is a void function and I don't know what use it is to >>probe the hash table after calling it. > >I think what Stuart wanted to express is that, contrary to deciding >whether to call Search() or Quiesce() for each move [like Crafty does >for example], he simply calls Search() for all moves, and if it is a >q-node he uses the result of Quiesce(), otherwise continues as usual ... > >Now of course one could argue whether there is any sense in probing the >hash table for the top-level q-nodes or not. I personally prefer to not >hash inside the q-search at all. > >>But if it works, by all means keep doing it. >> >>bruce I think Carsten is right. It just comes back to not doing hash table stuff when in quiescence. The effect of my earlier, old code which was 20% slower was to do a probe (not a store) at the first level of quiescence. That's an obvious slow-down if the corresponding store is not also there, not just the probe. Empirically it works, with a small test suite. I could test it further, with more time on the same suite or expand the number of positions, but I suspect the same thing would follow. The result is a speedup in nps that more than offsets the number of positions found in the quiescence top ply-1 that were stored somewhere "above" in the full-width search. The tradeoff is clear. --Stuart
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.