Author: James Swafford
Date: 09:41:44 12/03/04
Go up one level in this thread
On December 03, 2004 at 12:01:50, Antonio Senatore wrote: > >Hi friends: > >In order to make a bit faster my engine, finally I decided to use the operator >"&" instead of "%" to obtain indexes in hash tables, knowingly that with it I >couldn't use any size of tables. > >The theory says that the use of the operator "&" requires that the total number >of entries of the table should be equal to: >Total Number of Entries = (2^X) - 1 (with X = 1,2,3,... ,n). > >According to that, I used the following values: > >Table Size = 64 MB >Size of each entry = 32 bytes >Total number of Entries = 64 * 1024 * 1024 / 32 = 2097152 = 2^21 > >To check that everything worked well, I proceeded to calculate some indexes with >both methods to make sure that the indexes were the same ones. So (for example): > >HashKey = 0x994A80C1 (I use random numbers of 32 bits for Zobrist) > >Index using "%" >index = HashKey % Total Number of Entries => >index = 0x994A80C1 % 2097152 = 688321 > >Index using "&" >index = HashKey & (Total Number of Entries - 1) => >index = 0x994A80C1 & 2097151 = 688321 > >So both methods give the same index. After that I expected that my engine were >something faster but for my surprise, it played with the same strength and >speed. Why? Am I doing something bad? Because if everything is right, then it's >not worthwhile to use "&" and to lose freedom regarding the size of the tables. > >Many thanks in advance for any commentary that you can do and I apologize for my >english. > >Antonio I follow your math and it looks ok, but this is not the right direction if you're looking to make your engine stronger. Forget this piddly stuff. Concentrate on algorithms. Focus on your evaluation and move ordering. Reducing your branching factor is going to give you a MUCH bigger 'return on investment' than this type of stuff... -- James
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.