Author: Gerd Isenberg
Date: 14:26:51 03/06/06
Go up one level in this thread
On March 06, 2006 at 16:34:36, Dann Corbit wrote:
>On March 05, 2006 at 05:02:39, Gerd Isenberg wrote:
>
>>On March 04, 2006 at 13:55:12, Dann Corbit wrote:
>>
>>>On March 04, 2006 at 13:50:14, Dann Corbit wrote:
>>>
>>>>On March 04, 2006 at 13:47:50, Dann Corbit wrote:
>>>>
>>>>>On March 04, 2006 at 02:46:22, Gerd Isenberg wrote:
>>>>>
>>>>>>>OK. So you make an array of 128 function pointers then, and do this:
>>>>>>>
>>>>>>>status = method[hashval(BB)]();
>>>>>>
>>>>>>Yes, if you like, you can do either switch with a contiguous range as well.
>>>>>>But to get pure attacksets, there are no function pointers at all, but pointers
>>>>>>to bitboards.
>>>>>>
>>>>>>>
>>>>>>>PGO seems to take a lot of the sting out of missed branch predictions, but of
>>>>>>>course there will always be some.
>>>>>>
>>>>>>It would be interesting to see some pseudocode what your /* Do Stuff */ in the
>>>>>>cases does, to implement a kind of "ray-base" e.g. with the position you
>>>>>>mentioned recently. If you are interested in a1-h8 related properties of let say
>>>>>>square g7.
>>>>>>
>>>>>>[D]7k/3n2q1/5p2/8/6N1/2Q5/1B6/Q1K5 w - -
>>>>>
>>>>>There is probably a lot less magic in my stuff than you might imagine.
>>>>>
>>>>>First of all, I have direct attack bitmaps, shadow bitmaps, and half-pin bitmaps
>>>>>(I tried quarter-pin, but so far they seem to be too expensive for the payback,
>>>>>but half pin are clearly worthwhile). For this position, half pin is enough.
>>>>>Quarter pin positions are very rare.
>>>>>
>>>>>Anyway, the interesting guy is the pawn at f6. When I go to my switch, I will
>>>>>have precalcuated stuff against the full bitmap and also white and black, as
>>>>>well as piece.
>>
>>That is all very interesting. I still have only a vague idea how you intend to
>>implement your occupied cases. How to index your precalculated stuff?
>>
>>Cascading switches with subsets of occupied, like own-opposite pieces and/or
>>concrete piece types? I understand if you have that 128-state occupied switches,
>>you have all information where man reside on that ray. Also you are able to
>>distinguish occupied squares from both sides of the square in question.
>>
>>So for instance one could do something like this, calling functions for each
>>occupied case, passing two lists of occupied squares for both directions, while
>>the occupied squares and number of occupied squares are compile time constants
>>for each case:
>>
>>switch ( occupiedBB & mask[sq][sw_ne])
>>{
>> ...
>> case A1_B2_C3_F6_H8: // from square g7
>> return getRayBase41_dia1(g7, {f6,c3,b2,a1}, {h8});
>> ...
>> case A1_B2_C3_G7_H8: // from square f6
>> return getRayBase32_dia1(f6, {c3,b2,a1}, {g7,h8});
>> ...
>>}
>>
>>// 41 1111x1
>>SRayBase* getRayBase41_dia1(SqType sq, SqType four[], SqType one[])
>>{ // "switch" on the pieces on the board of sq and square lists
>> ...
>> // look for pins/halfpins
>> if ( isOwnKing(one[0]) ) {
>> if ( isOppositeDiagonalSlider(four[0]) ) {
>> // sq is pinned
>> ...
>> } else if ( ownPiece(four[0]) ) {
>> if ( isOppositeDiagonalSlider(four[1]) ) {
>> // board[sq] is "half" pinned
>> if ( isOppositeDiagonalSlider(four[2]) ) {
>> // board[sq] is "half" pinned by at least a double battery
>> if ( isOppositeDiagonalSlider(four[3]) ) {
>> // board[sq] is "half" pinned by a triple battery
>> } ...
>> } ...
>> } ...
>> } ...
>> } else if ( isOwnKing(four[0]) ) {
>> ...
>> } ...
>> ...
>>}
>>
>>If those generated functions are inlined with compile time parameters, all
>>precomputed "knowledge" is inside generated code, rather than in indexed tables.
>>Is this the right track?
>
>It's probably better than my idea. I just call the same function with different
>parameters, with masks that have been modified by previous calls.
I think, if you generate each incarnation of all 64*4*128 functions, you use
generated compile time parameters as consts inside each function anyway...
Integer templates may be applicable as well.
Surely the idea is very interesting - thanks for sharing it and answering my
somehow committing questions. Still i am a bit afraid about the huge number of
conditional branches - even if good predictable. amd64 branch target buffer has
2048 address entries, but of course future processors may further improve on
both, size of btb and also even better branch prediction heuristics.
Cheers,
Gerd
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.