Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: BitBoard challenge to Ernst A. Heinz and bitboard fans - no moderation

Author: Vincent Diepeveen

Date: 15:37:40 01/17/99

Go up one level in this thread


On January 16, 1999 at 22:23:17, Carsten Kossendey wrote:

>On January 16, 1999 at 14:37:49, Vincent Diepeveen wrote:
>
>>On January 15, 1999 at 22:09:04, Robert Hyatt wrote:
>>
>>>On January 15, 1999 at 21:26:17, Vincent Diepeveen wrote:
>>>
>>>>On January 13, 1999 at 07:19:54, Ernst A. Heinz wrote:
>>>>
>>>>>On January 13, 1999 at 06:13:30, Vincent Diepeveen wrote:
>
>[mega-snip]
>
>>>>At a PII-450 diep generates 250k attacktables a second in the position
>>>>after openingsposition+1.e4,e5 2.d4,d5
>>>>
>>>>I'm only using C code. Not a single assembler instruction is in my code,
>>>>as far as i know your bitboards are written in C? In that case
>>>>there is no unfair comparision.
>>>>
>>>>An attacktable is a table in my program of
>>>>int attacktable [2][64];
>>>>First i clean the attacktable, then i store for every piece all attacks.
>>>>
>>>>that includes
>>>>  a) piece that attacks      (what square it is from)
>>>>  b) number of attackers     (clear i guess)
>>>>  c) kind of piece           (pawn,knight,bishop ...)
>>>>
>>>>I need this to evaluate in my program, as it evaluates also 'relationships'
>>>>between pieces and mobility is also depending upon it.
>>>>
>>>>My mobility goes like this: i loop over all squares of a piece, including
>>>>xray squares and then find out how important control over such a square is
>>>>depending on all kind of chessknowlege where info from attacktable is
>>>>used using lookup of attacktable[c][sq] where sq are all squares that
>>>>need to be considered. And as i use this 'attacktable' info a lot,
>>>>i therefore store it in this a simple way in [2][64] array.
>>>>Every time i use something out of my attacktable i definitely not
>>>>am gonna add all values of the different bitboards *just* to get the
>>>>number of attackers. That would slow down my program *considerable*.
>>>>
>>>>Now a problem using attacktables with mobility is:
>>>>if you do all squares at once (otherwise bitboards not rewarding),
>>>>that is kind of tough, considering that values are different
>>>>for every square. So where i simply count a+b+c, where probably
>>>>a != b != c then you run into problems, as for a range of -50 to +50
>>>>you need to do 101 bitboard counts.
>>>>
>>>
>>>
>>>I've already pointed out that this is false.  Here's how to do this _fast_ on
>>>the cray:
>>
>>>first compute the bitmap for the squares a piece on "sq" attacks.  This produces
>>>a set of zeros and ones.  Then take a static const array sqval[64] where you
>>>have filled in the value of attacking each square.  IE values for e4 d5 and
>>>so forth, and _every_ value can be different.
>>
>>>ON the cray, we use the vector load instruction, but from this sqval[] array
>>>we only load the values with 1's set in the according bitmap.  We sum these
>>>and we are done, and it takes roughly 20 clock cycles to get the first value
>>
>>The problem is that according bitmaps. If value can range from -50 to 50
>>then you need to do this 101 times, because you need a bitcount for
>>every value.
>
>You don't quite seem to understand. You have a 64 bit quantity, and an array
>with
>64 integers (between -50 and 50, if you like). Then you say "for every 1 bit,
>add
>up the corresponding array entries" with a single instruction (or something
>along
>that line). No loop involved. You do this once, not 101 times.

I perfectly understand. I have a PII at home, not a many million cray
computer. Redefine it.

>>>from the sq array, and assuming you have 20 squares you attack, the entire
>>>thing will complete in about 50 clock ticks _total_.
>>>Not very inefficient.  So things you think are hard are actually trivial on the
>>>right hardware...
>>
>>A rude way of mobility can be done quickly. NO doubt. Please don't talk
>>about the cray. We're talking general audience here. General audience



>>doesn't have a cray nor alpha 533 and also will not buy it.
>
>The general audience should consider getting a PowerPC which offers the same
>kind of vector processing, only that you're limited to 16 bytes at a time, so
>you'll need four instructions for a whole bitboard.


>[snip]
>
>>I don't doubt we all generate that quickly. Actually in DIEP i generate
>>15 million move generations a second after 1.e4,e5 2.d4,d5 at a PII-450
>
>Nice number, but what are you talking about? 15 million calls to your move
>generator(s), 15 million legal moves, or 15 million pseudo-legal moves?
>And are we talking about captures, quiet moves, or both?  What does "generating
>a move" mean to you? Just say this piece attacks that square or store all the
>nasty info like what piece is captured and how this will affect the board state
>(e.g. castling rights, ep square, attack tables ...)
>
>Also just generating moves for the very same position over and over again is
>kind
>of silly. You could as well have your move generator check whether the current
>position is the same you last generated moves for, and just return a pointer to
>the previous result in that case. That will yield much more than 15 million
><whatever> ...
>
>So why not take a position and calculate the tree size to some depth (a la
>Crafty's
>"perft")?
>
>Also take note that bitboard based move generation works much better in
>positions
>where pieces can slide far.
>
>>>>
>>>>Assuming in all cases lossless code,
>>
>>This was my point. Your code is lossy to mine.
>>
>>>>Greetings,
>>>>Vincent
>>>>
>>>>>=Ernst=
>>>>
>>>>Please guys don't moderate Ernst too tough, if you do, then i dunno
>>>>what Heinz thinks of himselve.



This page took 0.02 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.