Author: Dieter Buerssner
Date: 14:29:18 12/12/03
Go up one level in this thread
The performance of your program seems quite comparable to my program using hash
tables for perft. I store the whole position, to be really sure (for faster
perft runs, the overhead óf doing this seemed not too high). I get on P4, 2.53
GHz, 350e6 bytes for perft HTs:
white ( 1): perft 6
entries 5468750 size 350000000 size_wanted 350000000
6: 119060324
Used 2.588 s
white ( 1): perft 7
entries 5468750 size 350000000 size_wanted 350000000
7: 3195901860
Used 32.301 s
white ( 1): perft 8
entries 5468750 size 350000000 size_wanted 350000000
8: 84998978956
Used 427.989 s
white ( 1): perft 9
entries 5468750 size 350000000 size_wanted 350000000
9: 2439530234167
Used 8929.689 s
I used the following struct for hash:
#define EXACT_PERFT 1
#define N_PERFT_DEPTH 2
typedef struct perfentry
{
unsigned long hash32;
#if EXACT_PERFT
unsigned char real_bd[32];
#endif
double nodes[N_PERFT_DEPTH];
unsigned char depth[N_PERFT_DEPTH];
#if EXACT_PERFT
unsigned char castle_flags;
signed char epsq;
#endif
} PERFENTRY;
So, each entry could store two depthes and node couunts. I only used 32 bits for
the first compare of position, and if the same, compare the whole board. In the
perft 9 run, there was no collision (all matching hash keys also gave a matching
position). I used another 32 bits of the hashkey to calculate the index in the
table. The program also considered index+1 and index+2 (when storing, it may
overwrite the entry with the lowest depth - when probing it will look at all
three entries). I did not tune it really, just started with this idea. Perhaps a
more simple scheme would work better.
I used double as a counter. With typical modern floating point implementations,
this will work well, until counters hit 2**54.
Regards,
Dieter
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.