Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Problems with BitBoards?

Author: Roberto Waldteufel

Date: 00:45:09 01/13/99

Go up one level in this thread


On January 12, 1999 at 20:26:26, Eugene Nalimov wrote:

>IMHO, there are the following drawbacks:

I have used bitboards from my earliest programs, when I tried also 0x88, but
found my search was slowed down due to ineficent capture generation, which
disappeared as soon as I started using bitboards. They are not difficult to
understand, they just take a little while to adjust to, but for anyone with a
sound grounding in binary logic, they are both a natural and elegant way to
represent chess information, IMHO


>
>(1) It's much harder to think in the bitboards terms; they are not
>for the beginners. 0x88 approach, for example, can be explained in
>one post (as it was done recently by both Bruce and Bob).


True, the coding is more challenging, but without bitboards how could the
program generate the captures first without wading through all the other moves
first, incurring a serious and totally unnecessary overhead?

>
>(2) (Maybe that's part of (1), too). Algorithms are not trivial.
>For example, it takes some time to understand rotated bitboards.
>

I think there is a difference in saying there is a problem and saying just that
it is hard to understand. The easiest way is rarely the most efficient in my
experience.


>(3) Large data structures are necessary. For example, the entire
>search part of the "fast and dumb" chess program that don't use
>bitboards and use mainly piece/square tables for evaluation
>(something like Fritz, if everybody is correct and Fritz is really
>such a program) can be fit into L1 cache on any modern x86 CPU -
>both code and data. Craftys' tables are much larger - that's why
>Crafty "likes" CPUs with fast L2 cache (PPro and Xeon).
>
>(4) Bad support in the development tools. Few C compilers supports
>64-bit integers on 32-bit platforms, and even in those few, often
>code quality is much worse than for 32-bit integers, or there are
>bugs in the code generators.
>
This is not a problem with bit-boards, it is a problem with inferior compilers
that do not support things they should. I can't comment about individual C
compilers, since I don't use C. My BASIC compiler offers 64-bit quad integers,
and the operations with them are fast. With some work I have made them even
faster with the use of 32-bit assembler coding. Don't forget the 64-bit mmx
registers - logical operations can be performed in a single 64-bit operation
within the registers. It is only when you have to extract the bits that you need
to move two 32-bit chunks to standard 32-bit registers for bit scanning. Quite
frankly, I am amazed that anyone would buy a compiler that is known to have bugs
in it's code generation, or that is known to generate inefficient code.


>(5) Often chess program starts as modification of the existing
>project (like Gnu Chess or TSCP). There are no bitboard programs
>with source available let alone Crafty, and modifying Crafty
>source is not for the beginners.

I don't call that writing a chess program, only modifying one. Writing a program
includes designing the entire data structure (hopefully for maximum efficiency)
and following through the design decisions with careful coding - not using
someone else's source, which relieves you of a lot of work, a lot of thought and
crucially limits you to the design restrictions of the original program, which
may or may not be optimal

If the intention is to produce the most efficient program, then difficulty
should not be feared, it should be expected. Chess programming is not easy, and
I think it is short-sighted to limit oneself to a particular data structure just
because it is simple. The criterion should be how efficient it is for the job at
hand, not how simplistic the coding may be.

Best wishes,
Roberto

>
>Eugene



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.