Author: Ernst A. Heinz
Date: 07:18:31 10/04/98
Go up one level in this thread
On October 03, 1998 at 19:09:59, Roberto Waldteufel wrote: > >Here's another trick. I don't know if anybody else has tried this, but it might >help improve efficiency when there are large numbers of tablebase hits in the >search. Normally the tablebase would store an evaluation like draw or +mate in N >or -mate in N. Now the search only needs to know win/draw/loss except at the >root, where the best move is also needed. We can store win/draw/loss in 2 bits >per position, which is less than the space to store mate in n type scores. By >making the tablebase very compact, we may be able to store it in RAM, increasing >speed by avoiding many disk accesses. When we actually reach a tablebase >position at the root, the 2 bits of information are insufficient, so we store a >second, larger tablebase on disk with a move for each position, and just look up >the move at the root (we could also store number of moves to mate, but that is >not necessary). Does this make sense? Roberto, You are absolutely right here -- with some improved indexing schemes (article already submitted to the ICCA Journal :-) you can compress *all* 3-piece and 4-piece tablebases to less than 16MB of RAM. I have done it in "DarkThought" since summer 1997 together with my efficient interior-node recognizers and it works great. "DarkThought" probes the databases at speeds of at least 500K nps and peaked at over 1M nps during the last WMCC in Paris on the 767MHz DEC/Kryotech Alpha-21164a. The tricky part is to write sound evaluation functions that fit together with your static evaluation. I am currently writing another article for the ICCA Journal which details exactly how I do it. Please stay tuned ... :-) =Ernst=
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.