Author: Eric Oldre
Date: 15:07:19 01/13/05
Go up one level in this thread
On January 13, 2005 at 17:47:32, Dann Corbit wrote:
>On January 13, 2005 at 17:43:43, Dann Corbit wrote:
>
>>On January 13, 2005 at 17:18:46, Eric Oldre wrote:
>>
>>>I have a rotated bitboard based engine. (Latista)
>>>
>>>My board representation looks like the following.
>>>
>>>//piece types
>>>typedef enum {
>>> PIECEEMPTY,
>>> PIECEWPAWN, PIECEWKNIGHT, PIECEWBISHOP, PIECEWROOK, PIECEWQUEEN, PIECEWKING,
>>> PIECEBPAWN, PIECEBKNIGHT, PIECEBBISHOP, PIECEBROOK, PIECEBQUEEN, PIECEBKING,
>>> };
>>>
>>>
>>>struct chessboard {
>>>public:
>>> /* other stuff */
>>>
>>> U64 bb_pieces[13]; //bitboards of piece locations
>>
>>??13??
>>
>>>
>>>};
>>>
>>>I noticed while reading the crafty source that Crafty uses a structure more like
>>>this.
>>>
>>>struct chessboard {
>>>public:
>>> /* other stuff */
>>> //bitboards of piece locations
>>> U64 wPawns;
>>> U64 wKnights;
>>> U64 wBishops;
>>> U64 wRooks;
>>> U64 wQueens;
>>> U64 wKings;
>>>
>>> U64 bPawns;
>>> U64 bKnights;
>>> U64 bBishops;
>>> U64 bRooks;
>>> U64 bQueens;
>>> U64 bKings;
>>>};
>>>
>>>so Prof. Hyatt can then use the following
>>>
>>>board->wPawns;
>>>instead of the equiv. in my engine
>>>board->bb_pieces[PIECEWPAWN];
>>>
>>>I've also noticed that Crafty is much faster than my engine, Although I'm sure
>>>that there are MANY MANY reasons for Crafty's better speed, I'm considering
>>>trying a switch to a board format similar to Crafty's.
>>>
>>>I know you can't perfectly predict what type of gain/loss I'd get, but I thought
>>>I'd ask if anyone thought It might be worth it.
>>>
>>>Or maybe you can tell me that it shouldn't make much difference and I'll save
>>>myself some time.
>>>
>>>Thanks for any advice you have,
>>
>>The separation by type is useful not only for move generation but also
>>evaluation.
>>
>>Also, you can do things by exact types (e.g. white pawn moves are different from
>>black pawn moves).
>>For example:
>>while (white_pawns_bitboard)
>>{
>>loc = get_and_clear_bit(white_pawns_bitboard);
>>do_stuff_with_white_pawn_at_loc(loc);
>>}
>>
>>Doesn't sound so great?
>>
>>Consider:
>>loc = get_and_clear_bit(some_bitboard);
>>switch(get_color(loc)) {
>>case WHITE:
>>switch (get_type(loc)) {
>>case PAWN:
>>do_pawn_stuff(loc, WHITE);
>>case KNIGHT:
>>do_knight_stuff(loc, WHITE);
>>/* ... etc for each piece type */
>>}
>>
>>break;
>>case BLACK:
>>/* like above for black pieces */
>>break;
>>}
>>
>>as you can see, all that switching and figuring out colors and types is not
>>needed if you store by color and type.
>>
>>mispredicted branches are like dropping bricks on your toes.
>
>Oops. Now I see what you are doing.
>The difference is almost irrelevant. I doubt you will see any change in speed
>at all. Possibly, the array lookup might be some miniscule bit slower than a
>direct element, but I think your notation might even be more convenient.
>
>I would not change that bit of your program. Speed difference is from something
>else.
Thanks Dann,
Your help is always apprieciated!
I was a bit confused after reading your first post. Glad you followed up.
When I first did the switch to rotated bitboard i did it the way described above
simply because It made sense to me, and I thought I'd seemed easier to work
with, esp considering the legacy code in my engine. At this point though I could
switch it with a couple nights work if it made sense.
It makes sense that the compiler should be able to figure it out. But I still
don't know any assembler so i have trouble verifing myself. But since crafty did
it the other way I thought maybe there was a good reason.
I guess this news is bitter sweet, no need to re-code a big part of my engine.
But no cheap gains in speed to be had either.
Eric
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.