Author: Robert Hyatt
Date: 18:32:56 06/19/00
Go up one level in this thread
On June 19, 2000 at 20:50:11, John Coffey wrote: >On June 19, 2000 at 19:48:36, Larry Griffiths wrote: > >>I have found bitboards to be an even trade-off on my Pentium system. I have to >>update about 6 bitboards when a piece moves and this generates a lot of >>instructions. I get it back in my IsKingInCheck code so it evens out. I like >>to have fast move generation code, but most of my gains have been through >>alpha-beta, hash-table, killer-move and movelist ordering etc. >> >>Larry. > > >Maybe I am too much of a novice, but I don't see yet why I should convert over >to bitboards. Is move generation faster? If so, why? My program scans the >board and uses simple loops to generate moves. Do you not have to do loops >with bitboards? Not to generate moves, No. You generate all the sliding piece moves with two table lookups... Now I can understand why evaluation might be faster with >bitboards because you can & and | your way through things. But I am trying >to evaluate the control of squares which I am not sure how to do with bitboards. See above. The main thing you don't do is "loop" down rays to find empty or blocked squares. a table lookup does the trick. Faster? maybe or maybe not. It is certainly faster to generate only captures with bitboards, because you _never_ even think about the 'empty squares". > I am experimenting with an incremental evaluation function that evaluates the >base position and makes changes to that evaluation as the position changes. >This is expensive, but my whole approach of evaluating >square control would be very expensive if I did it at the leaves. > >I am sure somewhere on the net is a really good explanation of bitboards. > >John Coffey
This page took 0.01 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.