Author: Uri Blass
Date: 08:06:16 01/09/01
Go up one level in this thread
On January 09, 2001 at 08:14:55, Severi Salminen wrote: >On January 09, 2001 at 06:37:54, David Rasmussen wrote: > >>On January 09, 2001 at 03:25:49, Severi Salminen wrote: >> >>>>It is a way to get all the squares to which a piece can move by a pseudolegal >>>>move. In a bitboard based program, it would just be a bitboard of all the places >>>>a piece on a given square can go to, given the configuration of pieces on the >>>>board, if we disregard placing the king in check. Of course this wont account >>>>for pinned pieces, overworked pieces, trapped pieces etc. But it will give you a >>>>good idea of the mobility of a piece. Similar ideas can be made with >>>>non-bitboard implementations. >>> >>>Ok, thanks! Now I now I'm using attackboards... >>> >>>Severi >> >>If you are using it, mobility won't be expensive. > >For some reason (maybe because I don't use rotated bbs) my program spends a lot >time generating moves. From profiler (7 ply search, Leko-Kramik game, endgame >pos.) I can see that generating moves (captures for both sides) takes 13% of >time. This number _excludes_ the time to perform SEE which increases the number >to 30%. Non_captures are generated very fast (maybe 2%). I'm doing some 90KNPS >on an old-type Celeron300(without cache). I have not tested it with modern >platform. > >Severi It seems that you do something wrong because I know that some top programs can see more than 100 nps on p200 that is probably slower than Celeron300. Top programs have more complicated search rules and more complicated evaluation so I expect a simple program that is optimized for speed to search more nodes per second. Uri
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.