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 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.