Author: martin fierz
Date: 04:35:17 02/12/04
Go up one level in this thread
On February 12, 2004 at 05:35:09, Uri Blass wrote:
>On February 12, 2004 at 04:59:29, martin fierz wrote:
>
>>On February 11, 2004 at 18:37:48, Dann Corbit wrote:
>>
>>>On February 11, 2004 at 18:29:53, martin fierz wrote:
>>>
>>>>On February 11, 2004 at 18:13:25, Dann Corbit wrote:
>>>>
>>>>>On February 11, 2004 at 18:01:44, martin fierz wrote:
>>>>>[snip]
>>>>>>hi dann,
>>>>>>
>>>>>>i am quite aware that a normal hashtable works as you say - store a key and a
>>>>>>score. but really, i think that is a much too simplistic view of pawn structure.
>>>>>>pawns interact with pieces in complex ways, and i basically would like to store
>>>>>>the information i think important about pawns in the pawn hashtable, to retrieve
>>>>>>them quickly later. i can also imagine storing a "baseline score" for the given
>>>>>>pawn configuration. but i really want interactions with pieces too, and as i
>>>>>>can't hash scores for that, i'd have to save intermediate computations (such as
>>>>>>connected passers, or potential levers etc) in the pawn hashtable, and then use
>>>>>>them for the interaction terms.
>>>>>
>>>>>I bet it will be more expensive to store all that stuff in the hash table and
>>>>>try to reuse it than to recalulate it.
>>>>
>>>>one hashlookup will cost something like the average memory latency for
>>>>non-cached stuff. that's probably around 50-100 processor cycles. if there are
>>>>more than 100 processor cycles in what i store, i should be fine.
>>>>
>>>>>The best thing about the pawn hash table is that the kings and the pawns move
>>>>>slowly. You don't see a ton of rapid change and so a small table gives a lot of
>>>>>hits. If you want to store things about rooks backing pawns and other things of
>>>>>that nature, I think the table will change quickly. What will you have? An
>>>>>ordinary hash table entry. So why bother with it?
>>>>
>>>>nope, that's not the idea. i want to store pawn stuff only, of course. but
>>>>instead of keeping a score, i would store, for example, a passed pawn bitboard;
>>>>or a bitboard with all bits set behind passed pawns. then a simple & with the
>>>>rook bitboard gives me supported passed pawns. you can imagine more complex
>>>>stuff to do, like you could look at the pawn structure and produce a bitboard of
>>>>squares where you think your king is safe and where not. then again, a simple &
>>>>gives you the answer.
>>>
>>>I guess what I am saying is that the benefit of a pawn hash will be lost if you
>>>do too much work. After all, all of the above calculations will be stored in
>>>the regular hash. So you will not redo them if you have seen the position
>>>before. And if something changes, you will have to recalculate.
>>
>>no, you are completely misunderstanding the idea. i want to store *intermediate*
>>calculations in my pawn hash, which are not scores at all, but simply
>>pawn-related stuff that i can use all over my evaluation. instead of computing
>>all that pawn-related stuff at every node. since these are only related to
>>pawns, i don't have to recalculate anything if the pawn structure doesn't
>>change. as an example, take the task of finding isolated pawns in a bitboard. i
>>don't know how to do this efficiently. my code to do this is extremely ugly and
>>slow.
>
>Here is my code for it(this is the code that Gerd posted so it is not exactly my
>code)
>
>
>BitBoard FillDownBoard(BitBoard bb)
>{
> bb|=(bb>>8);
> bb|=(bb>>16);
> bb|=(bb>>32);
> return bb;
>}
>BitBoard FillUpBoard(BitBoard bb)
>{
> bb|=(bb<<8);
> bb|=(bb<<16);
> bb|=(bb<<32);
> return bb;
>}
>
>
>pawnattacksAH[LIGHT]=(pawnBB[LIGHT]<<9)&NOTFILEABB;
>pawnattacksHA[LIGHT]=(pawnBB[LIGHT]<<7)&NOTFILEHBB;
>pawnattacks[LIGHT]=(pawnattacksAH[LIGHT]|pawnattacksHA[LIGHT]);
>isolatedpawns[LIGHT]=(pawnBB[LIGHT]&~FillDownBoard(FillUpBoard(pawnattacks[LIGHT])));
>
>pawnattacksAH[DARK]=(pawnBB[DARK]>>7)&NOTFILEABB;
> pawnattacksHA[DARK]=(pawnBB[DARK]>>9)&NOTFILEHBB;
> pawnattacks[DARK]=(pawnattacksAH[DARK]|pawnattacksHA[DARK]);
>
>isolatedpawns[DARK]=(pawnBB[DARK]&~FillDownBoard(FillUpBoard(pawnattacks[DARK])));
>
>Note that I do this code only when it is needed(only after pawn moves or
>captures of pawns that may change the isolated pawn information so I have if
>code to implement this code only when I make move or unmake move that may change
>the information).
>
>Uri
hi uri,
thanks for posting the code. i'll check whether this is faster than what i do.
just a short question, after looking at this code:
i can imagine the following might be faster:
-> get filldownboard(pawns)
-> %= it with 256
-> table-lookup in a table "isolated" with 256 entries which returns the columns
with isolated pawns
-> & with pawns to get isolated pawns.
i think if the table is in L2 cache the table lookup should be around 10 clock
cycles. then again, you only need about 6 instructions, on a 64-bit processor
that should be faster than my proposed table lookup i guess.
cheers
martin
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.