Author: Uri Blass
Date: 03:47:25 05/05/04
Go up one level in this thread
On May 05, 2004 at 06:35:46, Uri Blass wrote: >On May 05, 2004 at 06:25:23, Uri Blass wrote: > >>On May 05, 2004 at 06:08:34, Sune Fischer wrote: >> >>>On May 05, 2004 at 05:55:10, Uri Blass wrote: >>> >>>>On May 05, 2004 at 05:39:28, Sune Fischer wrote: >>>> >>>>> >>>>>> First you update the attack table with the move and then you generate only >>>>>>legal moves based on the attack tables , right? What i do is update the attack >>>>>>table and then generate "pseudo legal" moves,except king moves to an attacked >>>>>>square. So our difference is you have a routine which calculates only legal >>>>>>moves based on your attack tables. I don't see how that can speed up perft >>>>>>immensely. >>>>> >>>>>It can't :) >>>>>The speed up Uri gets in perft comes from not having to make the moves at the >>>>>leaf. >>>>>The moves are just generated and then counted and the makemove is saved. >>>> >>>>This is the speed improvement relative to other programs but I am talking about >>>>the speed improvement relative to my initial version and the trick of not making >>>>the last move was always used by movei. >>>> >>>>If you need the attack tables to generate moves then it is clear that updating >>>>them faster is going to cause a speed improvement. >>> >>>Attack tables will only slow down move generation, IMO. >> >>No >>They only slow the makemove function. >> >>The result of updating attack tables incrementally is significantly faster >>makemove. >> >>When I started and did not update moves incrementally making X moves was >>significantly slower than generating 30x moves when most of the time was used >>for updating the attack tables. >> >>> >>>I'd even say that the move generation is were you take all the penalty for the >>>attack tables, >> >>No >> >>see above. >> >> but then you hope to get the investment back on improved search >>>rules and evaluation. SEE should become a lot faster for instance. >>> >>>When I used them I also generated them incrementally and it was much faster than >>>from scratch. Like Omid says though, it probably depends on the design. >>> >>>>My intial version was very slow in calculating perft not only relative to movei >>>>of today but also relative to Crafty. >>> >>>I think it's hard to relate perft times with move generation speeds because you >>>use that trick, comparing Movei and Crafty here would be comparing apples and >>>oranges. >> >>perft is not about move generating speed. >>You can see from my explanation in this post that when I started it was mainly >>about make move speed inspite of the fact that I generated significantly more >>moves. >> >>Uri > >When I think about it then it is possible to push the part that update the >attack tables from makemove() to gen() so it is a question of definition of your >functions. thinking again and it is not so simple because updating the attack tables is based on the position on the board and I do it often in the middle of the move. After I add a piece to the board I need to update the attack tables and before I delete a piece from the board I need to update the attack tables. 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.