Author: Reinhard Scharnagl
Date: 07:21:00 09/06/04
Go up one level in this thread
On September 06, 2004 at 10:08:40, Uri Blass wrote: >On September 06, 2004 at 09:48:17, Uri Blass wrote: > >>On September 06, 2004 at 09:32:01, Reinhard Scharnagl wrote: >> >>>On September 06, 2004 at 09:21:36, Peter Fendrich wrote: >>> >>>>On September 06, 2004 at 09:06:06, Reinhard Scharnagl wrote: >>>> >>>>>On September 06, 2004 at 07:43:51, Peter Fendrich wrote: >>>>> >>>>>>What free programs have the fastest perft and what are the figures? >>>>>>Please, If you give figures also add processor, compiler and environment! >>>>>> >>>>>>I want to compare with a new concept that isn't coded yet... >>>>>>/Peter >>>>> >>>>>Hi Peter, >>>>> >>>>>see some of my (Smirf) results (still improved after measuring) at: >>>>> >>>>>a) without TT: [http://www.chessbox.de/Down/CRC_Test_03.txt] >>>>>b) with TT: [http://www.chessbox.de/Down/CRC_Test_04.txt] >>>>> >>>>>Regards, Reinhard. >>> >>>>Hi Reinhard, >>> >>>Hi Peter, >>> >>>>I'm not sure how to read this. A few questions: >>>>It says break time 75 sec but in the table I find 166 sec. Is it 166 that >>>>I should count as the ply 7 result? >>> >>>Break time does mean that the test run will be stopped, when calculating a >>>single Perft ply has used that time or more. >>> >>>>That will get 3195901860/166 = 19252421 n/sec Correct? >>>>Pretty fast! >>>> >>>>What environment/platform? >>> >>>(Pentium P4 2.79 GHz, MS VStudio C++ Compiler) >>> >>>>Finally, is this a MoveGen that you can use in normal play or do you have "perft >>>>tricks" in it (such as not doing MakeMove in the leaves and just count the moves >>>>in the move list)? >>> >>>I do not know what you are thinking of. You can see that I am also are counting >>>mates, which have to be detected first. But indeed, I have a move-generator >>>which produces fully informed moves (capture, e.p., check, double check, >>>mate ...). So using that hardly calculated information for to optimize perft is >>>no cheating. I think, that using a pseudolegal move generator is a trick >>>instead. >> >>I do not think that there is cheating there. >>It is impressive that you detect also number of mates. >> >>Movei does not detect checks or mates before it makes the move and it only >>detect checks and double checks even after making the move(the varaible >>checkingsquare is -1 when it is a double check). >> >>I suspect that it may be a good idea to add this information to my move >>generator if it can be done with a cheap price and the advantage is of course >>detecting mate in 1 faster and I will not need to search to see that the side to >>move can mate in 1(generating the moves of the side to move may be enough). >> >>Uri >I can add that it is probably not very expensive to detect mates in the move >generator(most moves can be detected fast as not checks) and the main problem is >to do it without bugs. > >The main problem is probably after detecting a check to detect mate when your >attack tables are not updated to the mate board position but to the position one >ply earlier. > >If I try something in the near future it will be probably only to detect checks >in move generator. > >It may do movei even faster because it may be possible to use this detection to >do things faster in the real chess program when the target is not to calculate >perft. > >Uri Uri, the reason why I do such a generating of fully informed moves is that it really could help to simplyfy the routines elsewhere. And having such differentiated statistics of move types could help me a lot in detecting errors in my generator (or hash key calculating) because there would be a need for it, as you can raise a lot more of errors here than in a pseudo- legal move generator. Those thoughts have been the arguments for me to have such perft run types. Regards, Reinhard.
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.