Author: Ross Boyd
Date: 14:26:03 03/18/05
Go up one level in this thread
On March 18, 2005 at 03:53:06, Fabien Letouzey wrote: >On March 17, 2005 at 15:35:14, Ross Boyd wrote: > >Hi Ross, > >Because I wanted the PVs to always be complete and for other (useless) reasons, >Fruit does not use the hash tables at PV nodes. > >I will change this only when I have code to complete the PV when truncated. > >All sorts of slow-downs like this one can occur, see also short mates that need >seconds. Note that playing strength is seldom affected, probably less than 10 >Elo. > >Fabien. Hi Fabien, Well maybe, that explains it then. However, with TRACE I have become envious of other engine's PV lengths... (it must be a male thing, ha ha), anyway, I tried things to stop the PV being truncated. The obvious one being to avoid hash table cutoffs or nullmove when following the PV. But it still solves Fine 70 in roughly the same time. So, perhaps the problem is caused by something else in Fruit. It may be the replacement scheme. This particular position has a tendency to generate TT 'log-jams' where previous depth-preferred entries block out newer entries and therefore makes the search a little bit 'stubborn'... if you know what I mean. Try always-overwrite temporarily for a quick test. Regarding code to complete the PV when truncated, one way would be to read it straight out of the transposition table when you get a cutoff, possibly, during the search if it doesn't cause too much overhead. Otherwise, retrieve it when the search completes. Keep up the good work Fabien, its a great engine. Ross
This page took 0.01 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.