Author: José Carlos
Date: 23:37:22 01/08/01
Go up one level in this thread
On January 08, 2001 at 20:31:02, Dann Corbit wrote: >On January 08, 2001 at 20:05:50, Landon Rabern wrote: > >>On January 08, 2001 at 14:23:48, Uri Blass wrote: >> >>>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 >> >>Yah, you can just get all the bitboards like normal, but then dont loop though >>and save the moves, just popcount the bitboards. Or if you only care about how >>many squares you can move to, not how many different pieces can move to those >>squares, you can or all the bitboards together and do 1 popcount. >> >>I have not tried adding mobility to my program yet, maybe I will. > >I'm not sure that counting moves will help a lot, or even if knowing you can >punch a hole will help. > >[D]2k2q2/8/3p4/2pPp3/1pP1Pp1p/pP3PpP/P5P1/2Q1K3 w - - > >This is a bad bishop sort of idea, but with only one piece that can punch a >hole, and (upon breakthrough) the piece dies. Still lots of places the queen >can move. But just no really useful ones. Every rule has exceptions. But think of it: usually, the more moves you can do, the more probability to find a good one. This isn't gonna happen for _every_ position (in that case, chess would be solved), but helps in many. For example, I remember when I starting writing my program, I implemented material and mobility before anywhing else, and I was surprised how logical moves the program did play with such a simple eval. José C. >Not that I have a better idea.
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.