Author: Robert Hyatt
Date: 20:40:15 06/28/02
Go up one level in this thread
On June 28, 2002 at 03:29:51, Gian-Carlo Pascutto wrote: >On June 27, 2002 at 17:29:51, Robert Hyatt wrote: > >>>If bitboards came without this penalty, you would be able to use them >>>whenever you can make the operation you're doing faster in bitboards. >>>I'd be a no-brainer to use them. However, this is not the case, and >>>you need to 'bet' that you will be able to recover the penalty you >>>incur because of this make/unmake updates, in other parts of the >>>program. >> >>Note that 64 bit machines reduce the penalty by 50%. 128 bit machines >>will reduce it by 75% since two bitboards can be updated in one operation. > >I don't believe the speedup is that good at all (harder to parallelize >for the cpu, memory limiting), but that is arguable. It must be. At least for the 64 bit operations. It says nothing about all the other stuff that is going on, like 32 bit address calculations and the like, of course. > >>>For the given eval example, this is not true. It can be used regardless >>>of what is used in the rest of the program. >> >>For some of the examples given, yes. Checking for "is it passed" is not >>as simple without bitmaps... Or "is it isolated" or "is it backward" or >>questions like "how many open files around the king" and the like. Anytime >>a question has several 'sub-questions' (status of a group of squares) then >>bitmaps offer the possibility of asking all those sub-questions with a single >>boolean operation, which is interesting... > >I think I disagree again. These are all very simple and very fast in my >non-bitboard program as well. (2 compares + 1 branch for the first two, >3 compares for the second one) Of course, one needs to get into the >non-bitboard line of thinking first before being able to make it that >fast :) > There is _no_ way to answer the "is it passed" in one operation without a bitboard. Unless you do some incremental computation in make/unmake to keep up with this instead. Then it becomes an apples-to-oranges comparison since the incremental cost has to be included. IE in Cray Blitz I kept up with the most advanced pawn on each file for each side, which did help. But the cost of doing that was non trivial as well, so that the "test" was cheap, but the "update" has to be factored in. In a bitmap program, there is no such incremental cost... >What bitboards are good for is stuff like 'how many pieces are within >2 squares of my king'. I can do this very fast without bitboards as >well, but bitboards allow me to do it anywhere in the evaluation, >which isn't possible in the classical approach (in my program). > >-- >GCP
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.