Author: Uri Blass
Date: 11:23:48 01/08/01
Go up one level in this thread
On January 08, 2001 at 13:41:43, Severi Salminen wrote: >>> >>>Well, generating moves is slow >> >>I guess that it is your mistake. >> >>I do not think that generating moves is slow. >> >>I think that generating moves if you are interested in pseudo legal moves and >>not in legal moves is very fast relative to other things that you want to do in >>your chess program. > >I must disagree on this one. Yes, I am interested in pseudolegal moves and my >engine also generates only them. But it is not _that_ fast. The question is what is your definition of being fast. I think that the right comparison is with the top programs. I know that top programs usually generate between 50 knodes per second and 500 knodes per second on pIII450. If generating all the pseudo legal moves takes less than 1/500,000 second then I think that you have no big problem. I also think that counting the moves is faster than generating them that means that you save the information about the moves to use it later. If you have bishop at c4 you need to check if the first piece in the direction d5,e6,f7,g8 and the first piece with it's colour determine the number of moves. You can continue for all the bishop's direction. It seems only few clock cycles for every move. I have reprogrammed >many move generation routines in assembler and they still take their time. I'm >using bitboards not rotated, though. But using pipelining facilities of modern >processors one can generate file moves very fast with only a couple of assembly >instructions or clock cycles. How many clock cycles do you need to generate a move? 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.