Author: Uri Blass
Date: 14:39:20 02/12/04
Go up one level in this thread
On February 12, 2004 at 07:35:17, martin fierz wrote:
>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
I do not know.
I am not expert in speed questions and the code that I use was copied from posts
of Gerd.
I never counted number of machine instructions or number of clock cycles
because I do not look in the assembler output.
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.