Author: Robert Hyatt
Date: 17:55:49 09/19/04
Go up one level in this thread
On September 19, 2004 at 19:20:31, Uri Blass wrote:
>On September 19, 2004 at 18:35:49, Sean Empey wrote:
>
>>On September 19, 2004 at 11:38:10, Uri Blass wrote:
>>
>>>On September 19, 2004 at 10:36:20, Robert Hyatt wrote:
>>>
>>>>On September 18, 2004 at 14:16:03, Stuart Cracraft wrote:
>>>>
>>>>>On September 17, 2004 at 20:52:19, Robert Hyatt wrote:
>>>>>
>>>>>>On September 16, 2004 at 21:20:50, Uri Blass wrote:
>>>>>>
>>>>>>>What is faster doing a loop on the 1's of a bitboard or doing a loop on array of
>>>>>>>integers
>>>>>>>
>>>>>>>I simply consider to change my knight move generator to bitboards
>>>>>>>
>>>>>>>Today I have array
>>>>>>>int knightmove[64][8] and the question is if getting
>>>>>>>knightmove[c3][0],...knightmove[c3][7] is faster or slower than getting the same
>>>>>>>squares by calculating the 1's of knightoption[c3] in order to get the squares
>>>>>>>that the knight can go.
>>>>>>>
>>>>>>>I also consider to have bitboard knightcapturewhite[64] knightcaptureblack[64]
>>>>>>>and knightquietmoves[64] that are going to be updated incrementally after every
>>>>>>>move and the question is what is the price of this in speed.
>>>>>>>
>>>>>>>Do people who use bitboards have experience with it?
>>>>>>>
>>>>>>>Uri
>>>>>>
>>>>>>
>>>>>>You are asking the wrong question. Bitboards are simply a way of doing
>>>>>>_everything_ differently from array-based board representations. There are
>>>>>>gains and losses (of course you should ignore the naysayers like you-know-who as
>>>>>>bitboards can and do work fine). But when you start to mix things, the only way
>>>>>>to see if it is faster is to simply implement and test. That's what I did with
>>>>>>rotated bitboards when I first thought of the idea. It seemed like a good idea,
>>>>>>but there were issues to overcome... It takes time and testing...
>>>>>
>>>>>If one doesn't want to go full bitboard for everything,
>>>>>then partial bitboard for evaluation...
>>>>>
>>>>>Speed of evaluation without the hassle of rotation...
>>>>>
>>>>>Stuart
>>>>
>>>>Then you have to convert mailbox to bitboard at _every_ q-search position. That
>>>>won't be fast...
>>>
>>>In my case I have no mailbox and my board is simply 0-63
>>>
>>>I know that bitboard do not beat mailbox in generating moves but I hoped that it
>>>may beat my method of generating moves.
>>>
>>>Here is my function for generating knight moves(assuming the knight is not
>>>pinned and I check if the knight is pinned first by my pin array that is updated
>>>after every move so there is no illegal move)
>>>
>>>color(target) is defined to be info[target]>>3;
>>>
>>>static void generatesimpleknights(int square)
>>>{
>>> int i,target;
>>> for (i=0;i<knightnumber[square];i++)
>>> {
>>> target=knightmove[square][i];
>>> if (info[target]==EMPTA)
>>> gen_quietnopawns(square,target);
>>> else
>>> if (color(target)!=side)
>>> gen_push(square,target);
>>> }
>>>}
>>>
>>>for generating moves in bishop direction I have today functions like the
>>>following function
>>>leftup[x]=x-9 when x-9 is in bishop direction relative to x.
>>>rightdown[x]=x+9 or -1 and is defined in the same way
>>>
>>>
>>>static void generate7(int square)
>>>{
>>> int target;
>>> target=leftup[square];
>>> while ((target!=-1)&&(info[target]==EMPTA))
>>> {
>>> gen_quietnopawns(square,target);
>>> target=leftup[target];
>>> }
>>> if ((target!=-1)&& (color(target)!=side))
>>> gen_push(square,target);
>>> target=rightdown[square];
>>> while ((target!=-1)&&(info[target]==EMPTA))
>>> {
>>> gen_quietnopawns(square,target);
>>> target=rightdown[target];
>>> }
>>> if ((target!=-1)&& (color(target)!=side))
>>> gen_push(square,target);
>>>
>>>}
>>>
>>>I wonder if I can have things faster
>>
>>
>>pre-compute your moves and generating knight moves would be extremely fast.
>>something like this for generating them.
>>
>>/*
>> * Function: GenWNM
>> * Purpose: Generates suedo legal moves for white knights
>> * Usage: N/A
>> * Version: See ExtVerInfo
>> */
>>
>>int GenWNM( BoardInfo* cBoard, int sq ) {
>> int *v, u, i = 0;
>> v = KNPreGen[1][sq];
>> u = *v++;
>> do {
>> if( cBoard->Color[u] != WHITE ) {
>> AddMove( cBoard, sq, u, 0 ), i++;
>> }
>> } while( (u=*v++) != STOP );
>> return i;
>>}
>>
>>Hope it helps you so if at all
>>
>>-Sean
>
>Thanks
>
>I already use array with precpomputed moves
>knightmove[64][8]
>
>The only difference is that I do not use pointers
>If I understand correctly you claim that changing the array to
>knightmove[8][64] and using pointers can do it faster.
>
>I do not understand why do you start with
>v = KNPreGen[1][sq];
>
>I think that it is more logical to have v=KNPreGen[0][sq];
>
>Do I miss something?
>
>Uri
KN[64][8] is _way_ better than KN[8][64]. with the first declaration, the 8
moves are adjacent in memory, and will probably be loaded into one cache line.
Reversing the dimensions will make 8 knight moves require 8 separate cache
lines, which is 8x slower, not even counting the stuff that gets displaced by
loading 8x more lines than you really need...
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.