Author: Gerd Isenberg
Date: 03:01:12 09/13/03
Go up one level in this thread
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. > >For computing passed pawns as bitboards you first need to compute openpawns and >pawnattacks > >In order to compute pawn attacks you need to compute pawnattack from both sides >and for computing openpawns you need to use the function FillDownBoard and >FillUpBoard. With SSE2 (128-bit XMM registers) i will do fillDown and fillUp with all right attacks, left attacks and the pawns itself - parallel for white and black pawns. These disjoint filldown an -up information are base to compute most pawn patterns very fast. I will store it in some "static" (like global) data structure for further need during eval. Anyway intuitively i feel, stroring these "cheap" information inside a hash-table is a waste of space. Gerd > >Uri
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.