Author: Uri Blass
Date: 12:00:27 12/06/01
Go up one level in this thread
On December 06, 2001 at 12:06:36, Robert Hyatt wrote: >On December 05, 2001 at 14:53:34, Uri Blass wrote: > >>On December 05, 2001 at 14:15:59, Robert Hyatt wrote: >> >>>On December 05, 2001 at 03:12:49, Russell Reagan wrote: >>> >>>>If I run any top chess program, eventually the program doesn't get any new best >>>>move. Is this because the next ply is simply taking too long, or is it because >>>>the engine isn't designed to do searches for long periods of time (like days or >>>>weeks)? >>>> >>>>In other words, is it possible to write a program that is better suited for >>>>searching to deeper depths if it were given, say, 1 year to search for the best >>>>move? Or are current algorithms about as good as we're going to get in long term >>>>analysis? >>>> >>>>Another way of phrasing this would be: Is there any difference between a program >>>>designed to analyze completed games over long periods of time and a program that >>>>plays chess at a shorter time interval? >>> >>> >>>A program "hits the wall" for various reasons. The most common is that once >>>you totally saturate the hash table, move ordering starts to break down and >>>the effective branching factor grows. >> >> >>I do not think that the effective branching factor of Deep Fritz grows at long >>time controls. > > >It _must_. To see how bad it can get, disable hashing completely and check >the branching factor. I cannot do it with Fritz and I can only reduce the hash tables I remember that 64kbytes was the minimal for Fritzin the past and I suspect that the minimal for Deep Fritz is even higer. I can use hash of 1 Mbyte but I am not sure if I can use less than it. even if the branching factor with small hash table is not constant it does not prove that the branching factor with big hash tables is not close to be constant. I saved a lot of analysis with Deep Fritz and my experience is that the branching factor is often 3 or even smaller at long time control(Deep Fritz(64 mbytes) on p800 used many hours). I did not investigate if it is constant but I did not see significant difference(I may post my analysis later when I have excess to the right computer and people may try to calculate the branching factor of Fritz based on my analysis) I remember that Fritz5 had bad branching factor at long time control but my experience with Deep Fritz say that it is not the case with it. Since that is the critical path to passing good moves >around in the search for move ordering, doing without it is a killer. And >for very deep searches, you _must_ run into this problem because the hash >table size is tiny compared to the tree size for a 3-day search. I almost did not do 3 day search but I certainly did many searches of more than 10 hours at 600K nodes per second. <snipped> >This really doesn't matter. If you finish an iteration, you will search _all_ >moves at the root, even if one is out of order due to an overflow in node >count. Won't produce a wrong answer or anything else... It may be slower in the last ply because of this. Uri
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.