Author: Uri Blass
Date: 06:38:58 01/06/03
Go up one level in this thread
On January 06, 2003 at 09:28:53, Robert Hyatt wrote: >On January 06, 2003 at 02:19:13, Uri Blass wrote: > >>On January 06, 2003 at 02:02:34, Bruce Moreland wrote: >> >>>On January 05, 2003 at 23:21:40, Russell Reagan wrote: >>> >>>>It's probably best not to, since it is a linear improvement to an exponential >>>>problem. Where the real improvements in playing strength will come from are >>>>exponential improvements to the exponential problem (like null-move knocking >>>>that branching factor down). Of course, I'm sure you already know this, and this >>>>is your clever way of making others think about it for themselves and discover >>>>the answer on their own, giving us all a greater sense of accomplishment and >>>>self worth (not to mention saving us a great deal of time) ;-) >>> >>>Yes, I agree with this. The real improvement comes in doing new stuff, not in >>>making the old stuff a few percent faster. >>> >>>Which is why I brought this up. If I could decrease bf by a few percent I'd get >>>more speedup than I would by performance twiddling for years. >>> >>>bruce >> >>In my case I found that thinking about new stuff gave me idea to improve the >>speed of Movei. >> >>I thought about implementing one of Ed's ideas and I found that changing my move >>generator to find the biggest capture take too much time inspite of the fact >>that movei generate the list of the legal moves >>before making a move because I like to have the ability to use information about >>that number for extension and pruning decisions. >> >>I decided to have special function of generating moves for non captures and >>captures and it made my move generator faster. >>I continued with adding special function for generating white pawn moves and >>black pawn moves and even the function of white pawns I divided to generate pawn >>move one square,generating pawn move two squares... >> >>I believe that it may be possible to improve the speed of all part of the >>program by a factor that is bigger than 2 but new data structure is needed and >>it is not simple to do it. >> >>I believe that all programs do too much the same thing again and again. >>One example is that programs usually do not use the list of the moves 2 plies >>earlier for generating moves and I believe that a big gain can be earned from >>doing it but it is not simple to do it with no bugs so I even did not try to do >>it. >> >>Uri > > >Some do that. Including an early version of Crafty. However, generating >all moves _can_ be faster than incrementally updating the move list from >two plies earlier, which is why hardly anybody does this today. It is possible to remember for every piece a list of moves and in this case it is possible to try to update the move list incrementally only for pieces that did not move(because pieces that moved have usually different move list). Did you try to do it in that way in an early version of Crafty? 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.