Author: Sune Fischer
Date: 01:15:35 12/05/02
Go up one level in this thread
On December 04, 2002 at 23:27:46, Russell Reagan wrote: >On December 04, 2002 at 17:13:02, Russell Reagan wrote: > >>Good point. It could be even better than you think. For example, when the time >>comes when we can get rid of the board array in bitboard programs, and >>efficiently determine what piece is on a given square from the bitboards alone, >>it would be sufficient to use the b & -b trick to get a bitboard with the lowest >>bit set, and you could simply use that as a "from mask" for the piece being >>moved. But since we have the board array, you need an index, not just a 64-bit >>mask. > >I did some tests. I wrote a function to determine which piece is on a square >using only bitboards. It's just a bunch of if statements. Suprisingly, the >if-version of "what piece is on this square" is only about twice as slow as the >"piece = squares[i];" version. That is not as bad as I thought, but ask yourself how often do you need this information. I think you will be needing it a lot when you begin building a sophisticated eval(). I don't believe it is a good idea to do the whole design of the engine around the move generator alone, you should consider what you will be needing in all the other phases. Ie. if move generation is 20% of your time and eval() is 50%, then you really ought to be more worried about how to optimize the evaluation and choose some structures that aren't too information limited/expensive. This is the reason I use incremental attack tables, slowdown once and for all on the move generator, but speedup _everywhere_ else :) > I went on and did some testing with the b & -b Okay, I'm going to ask now. Can someone explain to me the meaning of b& -b? My compiler generates a warning that changing a sign on an unsigned accomplishes nothing, so the expression reduces to b & b which is b? >method and I found that for move generation, it's about 15% faster than the >version that uses bsf. Not only that but my make move function will be faster >too, but I haven't had time to test how fast yet. I was just testing to see if >this was faster, and since it is, I'm going to go ahead and switch over to it. You should try it, the idea is very neat. I think I will consider it too when we get those Hammers :) >I'm starting to really like this. Non-rotated bitboards, no need for a >first_one() type function, and virtually no lookup tables. Don't you need to index the zobrist table, for instance? -S. >Russell
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.