Author: scott farrell
Date: 00:52:51 11/29/03
Go up one level in this thread
On November 29, 2003 at 03:00:08, Gerd Isenberg wrote: >On November 28, 2003 at 21:27:52, scott farrell wrote: > >>Thanx Gerd, >> >>It gave a few percent speedup, funny thing is I didnt think of just fiddling >>with the current code, I was thinking more of ripping it out, or trying a >>non-table based approach. > >May be traversing your bitboards with finding lsb instead of msb is faster. >You should try the approaches of Walter Faxon or Matt Taylor (look in the >archives). I recently posted Matt Taylor's C-routines here: >http://www.talkchess.com/forums/1/message.html?331101 the lsb made about another 5% improvement, and java inlined it better than the msb for some reason, so that is good also. I couldnt get the lsbandreset to work, becase my bitboards are primitive, and I cant pass by handle. now I have to work out to reduce the work in the incremental tables. many many thanks Scott > >About your incremental make/unmake move algorithm, i did similar in my former >dos-program - but don't like the runtime dependency on the number of changed >controls per move anymore. I used 32-attackTo bitboards only addressed by some >piece index from 0..31 (0..15 white pieces, 16..31 black pieces) and redundant >32-bit piecesets attackedBy[64] for each square. That saves the need of updating >some squares on the ray where sliders move. For instance if a rook (e.g. with >piece index 13) moves from h1 to h2, there is no need to update >controlledBy[h3..h8], because the piecesets don't change. Of course one needs >two arrays, to to map piece indices to squares and vice versa. > >Gerd > ><snip>
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.