Author: Eugene Nalimov
Date: 20:02:46 04/10/00
Go up one level in this thread
On April 10, 2000 at 20:26:12, Robert Hyatt wrote: >On April 10, 2000 at 18:45:23, Eelco de Groot wrote: > >>On April 10, 2000 at 14:45:13, John Coffey wrote: >> >>>Let me get this sraight.... >>> >>>1. hash is the transposition table. >>>2. hashp is pawn structure caching? >>>3. cache is used for tablebase caching? >>> >>>How does one cache tablebase stuff? It is all endgames so I am not sure I see >>>the benefit. I guess that the exact same endgame could arrise in multiple >>>continuations. >>> >>>John Coffey >> >>I don't know much about how these hash tables are built up, -I do think you are >>right about hash, hashp and cache-, but if the number of pieces on the board >>goes down the number of transpositions that you will see in a typical position >>and chess-tree goes up by a lot. That's why hashtables (transposition tables) >>are especially effective in endgames. So that would also be true with only 3 to >>5 pieces on the board then. If you can search the transposition tables faster >>than the endgame tables on CD or on harddisk, compressed or not, such tablebase >>caching would pay off. I don't know if for Robert Hyatt's Crafty on the Quad the >>tablebases are also accessed while they are still compressed? In that case >>transposition tables would I think be faster still. But once a program is >>actually in a 3 to 5 piece sitation, would it then not be possible to use all >>room in the normal hash for just the endgame tablebase caching? And, if in >>Shredder's case the endgame tables are still on (Turbo-)CD I don't understand >>why Shredder wouldn't profit from more than 4 Mb? As I said I don't know that >>much about the subject. If maybe somebody could edify a little? (Like Dan's >>Encyclopedia Brittannica I mean?) >> >>Thanks >>Eelco > > >As counter-intuitive as it sounds, compressed on-the-fly accesses are faster >for almost all machines. A compressed block has to be decompressed, for >certain. But you read in more useful data in a compressed block than in an >uncompressed one (several times as much data). Which means that when using >compressed data, the effective I/O thruput goes up by a factor of 5 or more, >which more than offsets the time to decompress... > >I am using compressed databases (with raid0 in linux) to _really_ make I/O >fly... One more point: file I/O in ANSI/ISO C/C++ is not thread-safe, so when reading from the file I have to block other threads that are trying to access the same file. With compressed TBs that blocking interval is smaller. That means that multithreaded program can benefit from using compressed TBs even when disks are relatively fast. Eugene
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.