Author: Robert Hyatt
Date: 07:52:36 01/13/99
Go up one level in this thread
On January 13, 1999 at 07:19:54, Ernst A. Heinz wrote: >On January 13, 1999 at 06:13:30, Vincent Diepeveen wrote: >> >> [...] > >Vincent, > >As usual you spread your own fallible impressions and interpretations >in a style that suggests they are proven facts. But indeed they are *not*. > >The "problems" (rumors?) you allude to in the post only show that you have >*not* understood what bitboards are capable of and how to handle them >effciently. You are of course free to criticize Bob's coding style and his >design decisions in "Crafty". However, only inexperienced and narrow-minded >people draw general conclusions from just a single example (i.e. the source >code of "Crafty"). There are many ways to do things differently with bitboards >and rotated bitboards than in "Crafty". Overall, your post mainly elaborates >on some of Bob's design decisions which you deem non-optimal. > >The only real disadvantage of bitboards at the moment is the obvious penalty >of 64-bit integers on 32-bit CPUs which comes hand in hand with unfortunately >limited compilers and programming environments. > >=Ernst= Two other comments. The last point Ernst makes is not really a bad issue, because bitboards do one nice thing on 32 bit machines... they provide two very independent parallel instruction streams (upper 32 bits and lower 32 bits) that keep dual pipe machines very happily chewing instructions, while other programs have lots of places where one pipe is idle due to data dependencies. Second, as I have said many times in the past, Crafty is not particularly written to be as fast as humanly possible. I am following the software engineering practice of 'design for change'. I try to write code that is easy for me to understand, and easy for me to modify later. Some things have been hacked on, because they are "finished." Other things are left written in a clear style since they are not finished. Most of Vincent's points come from not having tried bitboards for any length of time. It takes time and experience with them to make them 'natural'. After doing this for going on 5 years now, I'd say that there is nothing that can't be done in _either_ (offset or bitboard) approach. But without bitboard experience, some things might be difficult or confusing. Vincent mentions the And(x,y) stuff in crafty as being "necessary." That is wrong. long long/__int64 can do a|b where a and b or 64 bit 'things'. I use the Macros (not functions, vincent, but macros) because older Macintosh machines didn't have 64 bit stuff and we _had_ to use functions to compile there. I am slowly removing them since the macs now have 64 bit support. But it was done not out of necessity on MSVC/GCC, but because of a demand for a Macintosh port. The only point I'd agree on is that bitboards are harder to get started with, because the 'bit-parallel' way of thinking takes some getting used to. But once you pass that hurdle, bitboards are _not_ a handicap. If you remember nothing else, remember this: "bitboards are an alternative data structure, and nothing more or less. they are _not_ an alternative approach to writing a chess program. They can do no more, nor no less than the offset approach. And on 64 bit architectures, their information density is better than an offset program making them probably perform better."
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.