Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: A question about move generators for bishops and rooks

Author: Gerd Isenberg

Date: 02:06:13 04/07/04

Go up one level in this thread


On April 06, 2004 at 18:15:40, Vaclav Visnadjek wrote:

>Last year, the following occurred to me:
>–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
>BITBOARD *bishopmoves(POSITION *posit)
>{
>bishmoves=calloc(64,sizeof(BITBOARD));
>int bishmovsq[28]={7,  14,  21,  28,  35,  42,  49,
>                   9,  18,  27,  36,  45,  54,  63,
>                  -7, -14, -21, -28, -35, -42, -49,
>                  -9, -18, -27, -36, -45, -54, -63};
>int h;
>int i;
>for (h=0; h<64; h++)
>{
>   for (i=0; i<28; i++)
>   {
>        if (h+bishmovsq[i]>=0 &&
>             h+bishmovsq[i]<64 &&
>                  ((h+bishmovsq[i])/8+(h+bishmovsq[i])%8)%2 == ((h/8)+(h%8))%2)
>        {
>             bishmoves[h] |= mask[h+bishmovsq[i]];
>             if ((mask[h+bishmovsq[i]] & posit->allpieces) != 0)
>             {
>                  i = (7 * (1 + i/7))-1;
>             }
>        }
>   }
>}
>return(bishmoves);
>}
>
>BITBOARD *rookmoves(POSITION *posit)
>{
>rkmoves=calloc(64,sizeof(BITBOARD));
>int rookmovsq[28]={1,   2,   3,   4,   5,   6,   7,
>                   8,  16,  24,  32,  40,  48,  56,
>                  -1,  -2,  -3,  -4,  -5,  -6,  -7,
>                  -8, -16, -24, -32, -40, -48, -56};
>int h;
>int i;
>for (h=0; h<64; h++)
>{
>   for (i=0; i<28; i++)
>   {
>        if (h+rookmovsq[i]>=0 &&
>             h+rookmovsq[i]<64 &&
>                  ((h+rookmovsq[i])/8 == h/8 || (h+rookmovsq[i])%8 == h%8))
>        {
>             rkmoves[h] |= mask[h+rookmovsq[i]];
>             if ((mask[h+rookmovsq[i]] & posit->allpieces) != 0)
>             {
>                  i = (7 * (1 + i/7))-1;
>             }
>        }
>   }
>}
>return(rkmoves);
>}
>––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
>With all the necessary adjustments, can them be used as an alternative for
>rotated bitboards? If so, could the main idea help to increase the speed of
>calculations?

I fear no, your huge, expensive calculation don's pays off.

As far i can see, you calculate all 64 bishop/rook attack-bitmaps for each
square. The outer loop traverses all squares (64), the inner loop (28) traverses
over all possible targets. If a ray breaks early due to an occupied piece, you
go to the next direction.

Anyway you may need up to 64*28 = 1792 runs with some conditions and assignment
inside your loop. Even if you loop only ~800 times on average you waste a lot of
time - and that for each node?

You allocate memory for that attack arrays on the heap, calloc is slow too due
to the allocated array is initialized by memset with zero - you have too free
that memory later.

After that huge initialization work per node you safe a bit per attack getter.
For rooks and bishops you have only one direct array access.
With rotated lookup or rotated indizes you need two accesses each and some
fiddling with occupied state.

If you really like to calculate all attacks for each square,
even that initialization with rotated is much cheaper, despite a bit more update
stuff during make/unmake:

BITBOARD *rookmoves(POSITION *posit)
{
rkmoves=calloc(64,sizeof(BITBOARD));
int h;
for (h=0; h<64; h++)
{
  rkmoves[h] = getRotatedRookAttacks(h);
}
return(rkmoves);
}

But caching/precalculation of rotated lookup that way only pays off, if you
really need it very, very oftern per node for a lot of squares. And most of the
time you really dont't need attacks from all squares...

Maybe there are some tricks, to speedup your idea by doing some things paralell.
E.g. if you have right attacks from a1 and the attack vector contains all
possible sqaures from b1 to h1 - you may use that information to get right
attacks from b1 to h1. I once thought about a similar algoriths based on
kogge-stone fill...

Gerd



This page took 0.01 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.