Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: To bitboard or not to bitboard?

Author: Peter McKenzie

Date: 02:30:38 08/31/03

Go up one level in this thread


On August 31, 2003 at 01:03:46, Uri Blass wrote:

>On August 30, 2003 at 22:29:56, Sune Fischer wrote:
>
>>On August 30, 2003 at 14:37:44, Tord Romstad wrote:
>>
>>I think you have found some good arguments against bitboards,
>>but all representations have some disadvantages.
>
>I do not think that you have to choose only one.
>It may be better to have both so you can choose which one to use based on your
>needs.
>
>You pay by some static speed reduction but the advantage is that you increase
>your opportunities for future developement.
>
>>Ie. in other schemes you must struggle to keep order on a piecelist, getting
>>things reproducable seems pretty difficult to me with this.
>>
>>But looking at different source codes, I think the big difference
>>is that bitboards use large tables and in return have relative few branches.
>>Processors and compilers get better in branch pridiction and they get more and
>>more cache.
>>Which factor eventually will dominate I can't say, but I believe the cache size
>>will only grow and it doesn't even seem to be a problem nowadays, so the table
>>sizes I don't personally worry about too much.
>>
>>What I like about bitboards is that you can work on the entire board with just
>>a few masks.
>>
>>As an example, say you have in your move generator a stage where you would like
>>to generate non-captures to squares not attacked by opponent pawns.
>>
>>This would require you only to AND the attack board for the given piece with:
>>~(occupied | opponent->PawnAttacks())
>>
>>Something which is of course a constant and can be pulled out of the piece loop.
>>
>>For move generation, the advantage of bitboards lies not in the speed of which
>>it can add dumb pseudo legal moves to a list (who does this anyway?)
>
>I think that you do it even in the search.
>
>In case that you expect all the moves to fail low it is not logical to spend
>time on incremental move generator and it is better to generate all moves.
>
>, but in the
>>way it enables you to generate classes of moves with minimal overhead.
>>
>>A second classic example, is if you want to know if there is a pawn on the 7th
>>rank.
>>With non-bitboards you can do a loop with branches, or if you enumerate your
>>pieces in power of two's, you could do something like:
>>if (Pawn & (pc[a7]|pc[b7]|pc[c7]|pc[d7]|pc[e7]|pc[f7]|pc[g7]|pc[h7]))
>
>For that purpose you can also keep a 8 bit varaible that tell you
>the pawns in the 7th rank when you update after every move that change it.

Better to get that sort of information out of the pawn hash table.

>
>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.