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.