Author: Matthias Gemuh
Date: 04:34:07 02/16/04
Go up one level in this thread
>
>But on a somewhat related note, there is one little piece of information
>on your BigLion page which I have always found really weird: You write
>that you store the pseudo-legal move list in your hash table. I have
>never tried anything like this myself, but I find it hard to believe
>that it is really a good idea. Doesn't this make your hash table
>entries insanely big? Does it really give you a sufficiently big
>performance effect that it is worth the price?
>
The move list hashing code is still in BigLion but presently deactivated.
If I switch it on, it consumes about 50% of total hash, with thick entries
typedef struct {
BITBOARD HashKey;
unsigned short nMoveCount, nKingSq;
CHESSMOVE Move[MOVECOUNTMAX]; // 230 moves
} MOVEHASH;
typedef struct {
BITBOARD HashKey;
unsigned short nMoveCount, nKingSq;
CHESSMOVE Move[QMOVECOUNTMAX]; // 36 moves
} QMOVEHASH;
Already at this point, it is clear that BigLion is just a strange toy,
not really a chess engine.
Hit rates lie between 35%...65% in test suites, if I remember well.
I shall test again and tell you. Speedup and gain were 0% approx.
I experimented with generating and hashing only legal moves to reduce
entry size and eliminate legality checking in search. No improvement.
I tried sorting before hashing to save sorting time, but move ordering wept.
I did release versions of BigLion with move list hashing.
>
>I am not sure this
>is the right time to experiment with new pruning tricks. I have the
>impression that you still suffer from a few serious bugs in your search,
>and you should probably try to fix them before you make your search more
>complicated.
>
This is the type of advice I like. It is naked truth.
/Matthias.
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.