Computer Chess Club Archives




Subject: Re: perft records

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...
>>>>>Hi Peter,
>>>>>see some of my (Smirf) results (still improved after measuring) at:
>>>>>a) without TT: []
>>>>>b) with    TT: []
>>>>>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
>>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).

>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


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.