Author: Gerd Isenberg
Date: 13:14:14 08/22/03
Go up one level in this thread
On August 22, 2003 at 13:46:55, Steven Edwards wrote: >If you would trade 384 Kbyte of memory for an approximate one percent speed >increase, then read on: > >The traditional Zorbrist hash code scheme for accessing transposition tables >uses a table of constant values > > unsigned long long int HashManSqVec[manLen][sqLen]; // or 12 x 64 of eight >byte codes > >that is accessed whenever a man is put on a square or removed from a square. >The accesses and the exclusive or operations can be cut in half by adding a >second table of constant values > > unsigned long long int HashManSqSqVec[manLen][sqLen][sqLen]; > >generated from the first that gives transition hash codes where the second index >is the source square and the third index is the target square. > >So, instead of > > theHash ^= HashManSqVec[man][source] ^ HashManSqVec[man][target] > >we have > > theHash ^= HashManSqSqVec[man][source][target] > >Perhaps someone could install this into Crafty so we could have some independent >performance measurements. Hi Steven, the question is how much does the additional memory pollute second level cache? The chance of expensive cache misses is higher with additional 384 KByte - on the other hand only one lookup instead of two. What about this one, to handle captures, promotions, castles and en passant? theHash ^= HashMoveKeyVec[movekey] Even if you shrunk the table with some sophisticated index scheme to 1 MByte or less, the chance of a cache miss is raising enormously. May be one advantage of this approach is to get rid of bitscan and to calculate "movekey" directly with some magic De Bruijn multiplication from single isolated source/target bitboards. Regards, Gerd
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.