Author: John Stanback
Date: 12:52:28 06/20/00
Go up one level in this thread
On June 19, 2000 at 20:36:28, John Coffey wrote: >On June 19, 2000 at 18:56:14, John Stanback wrote: > >>On June 19, 2000 at 18:38:12, John Coffey wrote: >> >>>On June 19, 2000 at 16:54:46, Tom Kerrigan wrote: >>> >>>>On June 19, 2000 at 16:27:58, John Coffey wrote: >>>> >>>>>Let us say that I have a system with not much RAM, like the Gameboys that I >>>>>program. Transposition tables are out of the question. The Gameboy Advanced >>>>>(16 mhz risc processor) has 1/4 meg available as an option that can be placed on >>>>>an external cartridge, but I figure that is not enough to do anything. >>>> >>>>256k is a terrific size for a hash table, esp. if the processor is 16mhz. >>>> >>> >>>Assuming that you could get 4,000 positions per second. 256K is about 16K >>>positions. You would fill up the table in about 4 seconds. Still it might >>>prove useful. >>> >>>John Coffey >> >>I agree with Tom, even a tiny table with 4K positions is a lot better >>than nothing. Use depth priority replacement for at least 1K positions >>to get good ordering near the root and "replace always" for the rest. >> >>John > >Why is this effective? Why not use depth priority all the time? > >John Coffey It actually turns out that if you had to pick only one simple replacement scheme, always replace is better than replacing only if depth >= entry.depth. This is because the vast majority of nodes in the tree are at very low depths (1,0, or negative). If you fill up the table with positions with higher depth you greatly reduce the number of hits since you aren't storing positions which are "locally revalent" to this portion of the tree. John
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.