Computer Chess Club Archives




Subject: Re: Problems with BitBoards?

Author: KarinsDad

Date: 07:23:32 01/13/99

Go up one level in this thread

On January 13, 1999 at 06:13:30, Vincent Diepeveen wrote:


>If you want to make a huge evaluation using mobility and attacktables
>extensively in search, then you have a major problem with bitboards.

Strange. I have both attacktables and BitBoards in my code and I haven't
experienced any problems.

>Also at 32 bits machines bitboards are rather slow compared to 0x88 and
>similar datastructures.
>Main problem has to do with L1 cache and especially the 64 bits length
>of a bitboard. Rotated bitboards in crafty eat 1MB
>of storage. Doesn't fit in 32 kb L1 cache of PII or Xeon... :)

Well, there you have it. My bitboards take up 144 bytes (not including my 2-3
KBytes of lookup tables), so they should work in cache.

>However as you see in crafty enough speed gets left, so problems come
>down to the point that you can't write a huge evaluation using bitboards,
>as at a certain point speed isn't the weakest chain anymore.

Since I have attacktables, a larger evaluation should be possible.

>In crafty mobility is the summation of squares attacked. If you want to
>do something with a square, like discriminating between a1 and d4 (controlling
>d4 is generally better than controlling a1), then bitboards give problems.
>Finally, bitboards are programmed for every piece.
>When i generate moves, i am using general code, so 10 lines of
>code which works for every piece. Crafty has written down
>code for every piece, so it's more work using bitboards too, both in
>coding and in updating datastructure.

This is true. My BitBoard code for rooks, queens, and bishops is different than
the code for pawns, knights, and kings.

>Then there is the huge coding needed for the functions. In order to be
>compatible, crafty is using functions which *should* be a single instruction.
>Like if i do: a = (b|c|d)^0x07;
>then that's about 18 characters, new line not included.
>In crafty that's much more than 18. To do b|c at a bitboard it needs a special
>function calls, and no matter whether it gets translated to '|', you
>need to write down that code.
>that means that 10 lines of C code from me are usually equivalent with at least
>20 lines in crafty. then there is some nice comment, which makes it another
>10 lines larger. so 3:1 would be rather good.
>That means that to do something bitboards is way more work.
>However, main problem is that it is not practical to create metaknowledge
>like attacktables using bitboards.

This, however, is false since I am doing it.

>To say that it's slow using bitboards would be an understatement.

That I do not know for sure. Preliminary tests indicate that they are slightly
faster, however, I haven't tweaked them yet either.

>In my evaluation i'm using extensively whether a square is attacked (so for
>example f6-f5 is not possible, which makes f6 weak). Therefore i generate
>a whole attacktable for both colors. Now very important is to know
>for example the number of attackers.
>To get my # attackers i just need an array lookup, so in a[i] somehow is my

Yup. That's how I'm doing it.

>Now that works rather quickly.
>only quicker is to have info in a variable.
>Using bitboards however generating an attacktable for all squares is
>a big disaster. In fact that function is not even in crafty. It has
>only a function that can collect the attackers of a single square,
>and that's already rather slow.
>So main problem of bitboards is implied in the definition. It has only
>a single bit for a square, so it's tough to represent more info about something
>than a single bit. Now if you need a 'collection' of info, like #attackers
>and what kind of attackers, then a single bit is not gonna give what you want.
>the more knowledgeable a program gets, the less helpful a bitboard-only
>solution is.
>So my advice is to not start with bitboards. That keeps away attention
>from other things, like making an evaluation.
>If i think out a new pattern, then i want to write it down in a recognizable
>form. My experience is that there are usual bugs in patterns when they are
>new. For me it's very important to be able to easily read my code back
>when concerning evaluation. Bitboard code is tough to read. Very tough.
>So concluding bitboards are:
>   - a lot of work
>   - slower
>   - needing always the newest machine to get that huge data
>     quickly out of L2 cache (Pro,Xeon,Tanner...)
>   - hard to read
>   - if you want to make a huge evaluation then you can't do some
>     very necessary things with mobility and attackers.
>Vincent Diepeveen


Thanks Vincent. Cannot say that I've seen your kind of results, but it's good to
know where other people ran into problems.

KarinsDad :)

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.