Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Pawn hashing without Zobrist keys

Author: Uri Blass

Date: 04:40:45 09/13/03

Go up one level in this thread


On September 13, 2003 at 06:01:12, Gerd Isenberg wrote:

>On September 13, 2003 at 05:25:36, Uri Blass wrote:
>
>>On September 13, 2003 at 03:06:21, Gerd Isenberg wrote:
>>
>>>On September 12, 2003 at 20:58:33, Vincent Diepeveen wrote:
>>>
>>>>On September 12, 2003 at 17:00:25, Gian-Carlo Pascutto wrote:
>>>>
>>>>minimum number of bits to store somehow either by index or non-index is
>>>>
>>>>48 bits (1 = pawn, 0 = no pawn) + 16 bits ( 1 = white, 0 = black ) = 64 bits.
>>>>
>>>>So that is going to be massive overwriting. of similar structures at the same
>>>>adress. Very poor for hash %.
>>>
>>>Why do you reply to Gian-Carlo and not to me?
>>>
>>>Hitrates with (whitePawns-blackPawns)%49981 are not that bad.
>>>Show me some different pawn positions, which map to the same 48-bit white-black
>>>difference...
>>>
>>>>
>>>>Skip bitboards.
>>>
>>>Not in geneneral of course - maybe for this purpose.
>>>That's not a bitboard issue - it's about using power of two sized tables.
>>>
>>>>
>>>>Just use Zobrist and AND.
>>>
>>>Yes, i will try it and report the speed gain...
>>>
>>>>
>>>>DIEP's pawnhashtable is like 4MB anyway and never bigger. I never understood
>>>>those large sizes for pawn hashtables. Soon i can get rid of the thing
>>>>completely when the last couple of hundreds of patterns get extra conditions, so
>>>>getting difficult to cache.
>>>>
>>>
>>>I found a range of 32-64K entries appropriated,
>>>results in the memory size you mentioned.
>>>
>>>Due to fast bitboard routines to get all kinds of pawn patterns,
>>>i'm also thinking about throwing out pawn hash tables...
>>>At least i will not store easy to compute patterns like passed and backward etc.
>>>into pawn hash anymore.
>>>
>>>Gerd
>>
>>Why?
>>
>>Do you think that it is faster to compute all of this information and not to
>>remember it from the hash tables?
>
>I'm not sure. There is always this conflict between pure register computation
>and storing in memory. Using more memory increases the probability of cache or
>even more expensive tlb misses.
>
>Another issue is that pure register computation hides memory latency.
>
>>
>>Note that you do not need to remember the information as bitboard and you may
>>simply remember information like number of passed pawns and squares of passed
>>pawns.
>>
>
>I prefere fixed sized bitboards.

What is the advantage?
often the number of passed pawns is going to be 0 and in this case
using 64 bit number is more expensive(maybe except some machines of the future).

Even if the number is bigger than 0 then reading the squares from the hash seems
to me less expensive than calculating the squares by firstone function.

Unlike you
I have no intuition here because I know that intuition tells me thing that are
wrong.

intuition tells me that checking if a 32 bit number is 0 should take more time
than checking if  a 8 bit number is 0 because you need to do 32 checks in the
first case and 8 checks in the second case.

I know that it is not the case because things are done parallel
but even here I think that if you check if 8 bit number is 0 then you can do
more things parallel and I do not understand why there is no general rule that
comparing 8 bits is faster than comparing 32 bits.

Uri



This page took 0.01 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.