Author: Robert Hyatt
Date: 19:39:57 04/02/01
Go up one level in this thread
On April 02, 2001 at 16:40:38, Heiner Marxen wrote: > > >I'm not so sure that this is always correct. >When we throw enough cache memory at the EGTBs, such that cache misses >become rare enough, EGTB probes will be fast on average. At some point >they can be fast enough that it is worth it. I don't think you can throw enough memory at EGTB Cache to stop file I/O. 3-4-5 piece files would need over 7 gigs of memory. If you throw in the already done 6's, you would need about 60 gigs... > >Another point is, that the cache built in to the EGTB software does use >much less memory than the normal cache for each stored position. >It _may_ be that the available memory is better used this way, >in which case it may not be the best idea to store these results also >in the normal transposition table. I would not say "much less memory". hash will only store positions actually used in the search. EGTB cache will have _all_ positions in a particular block of the file. > >There are several tradeoffs involved, here. I'm not at all sure, >what is the best choice under what circumstances. Some modeling >and some experiments seem to be necessary to know better. IMHO. > >Heiner I ran a _bunch_ of tests when Eugene and I were trying to figure out the optimal compression blocksize. I don't think it is as big a problem as it might appear at first glance. I've been probing these things forever and really don't see terrible performance hits the way I do it... with reasonable cache and hash settings it seems to work quite well...
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.