Author: Robert Hyatt
Date: 07:48:59 11/23/01
Go up one level in this thread
On November 23, 2001 at 00:11:12, Heiner Marxen wrote: >On November 22, 2001 at 19:41:30, Robert Hyatt wrote: > >>On November 22, 2001 at 15:52:22, Uri Blass wrote: >> >>>The times of my program in calculating perft(number of legal games of fixed >>>number of plies) are not bad. >>> >>>I get on p800 33 seconds for finding perft 6=119060324 in the initial position >>>and also 33 seconds for finding perft 5=193690690 in another known position >>> >>>this is not a mistake and my program needs similiar time because it generates >>>only legal moves so it needs less nodes to calculate perft 5. >>> >>> >>>[D]r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - 0 1 >>> >>> >>>I am interested to know what is the speed of the best free or commercial program >>>in calculating perft. >>> >>>Yace is the fastest free program that I know. >>>I do not know about a commercial programs with this function. >>> >>> >>>My move generator is not 100% correct because it has some probelms with the en >>>passant rule that I did not care to fix but it finds the right numbers and it is >>>clear that fixing the errors is not going to change significantly the speed of >>>the program. >>> >>> >>>yace is slightly faster than my program in caculating perft 6 in the initial >>>position(32 seconds) but has no chance in the second position and I plan to >>>improve the algorithm(there wer important things that I did not do because of >>>more important things). >>> >>>The main improvement that I worked about in the last days was improvement in >>>generating moves(my previous version generated only piece go to square when I >>>started from the target square and now I start from the piece except checks). >>> >>>second improvement that I found was a mistake of generating move twice when I >>>did not need to do it. >>> >>>I calculate perft 4 in the following ways: >>>1)generate all legal moves >>>2)make a3 >>>3)generate all legal moves >>>4)make a6 >>>5)generate all the legal moves >>>6)make a4 >>>7)generate all the legal moves and add their number into perft >> >>The original idea behind perft was to measure move generation _and_ make/unmake >>speed. IE if you do perft 4, a program would generate and make every move up >>to 4 plies deep. >> >>You are cutting off the last ply of make/unmake, which is ok, but it isn't >>comparable to the original intent of this. Otherwise everybody will go faster >>by dumping the last layer of make/unmake which is expensive... > >While I do understand your original intent (do I?), I have objections: >that way the resulting number is as meaningless as every other NPS number, >i.e. comparable between different versions of the same program, but not >at all between different programs. It is meaningless in general. I wrote this about 20 years ago the first time. Se used it to do two things. (1) check the move generator as a 4 ply full tree traversal should produce an exact node count. We needed this when we first vectorized the move generator in Cray Blitz, as it had _lots_ of very subtle bugs at first. (2) give a rough speed estimate for generating and making/unmaking moves. We used this to see if we were faster or slower after making major changes (like the vectorized generator I mentioned.) It was _never_ (in my case) intended to be used as any sort of performance measure with other programs, other than to compare the node counts which _must_ be exact matches or else there is a bug in one of the two programs... > >On the other hand, computing that exact resulting number (from perft) is >a well defined job. Yes, it has not much to do with the normal job of >a chess program, but it really _is_ well defined. Computing it, just >that number, is quite independant of the methods and circumstances to >generate moves and to do/undo them in any program. Hence, it is a >candidate for a number to be comparable among different programs. >IMHO. That was the original intent. Never gave efficiency one bit of thought, just made it a simple generate/make/unmove test for comparison with different versions of my own code. > >Back to the facts... here are my numbers from Chest. I do not execute >the last ply, just count the number of moves in the generated move list, >which does contain just the legal moves. Also, executing a move in Chest >is expensive, and prepares the next questions/functions which may follow. > >I do this on a K7/600 (without any hash table). From the initial position: >FEN: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - >Counting width of legal tree, 6 plies deep... >Time (user) = 40.57 sec >dep #nodes quot sum nodes > 0 1 [ 0.000] 1 > 1 20 [ 20.000] 21 > 2 400 [ 20.000] 421 > 3 8902 [ 22.255] 9323 > 4 197281 [ 22.161] 206604 > 5 4865609 [ 24.663] 5072213 > 6 119060324 [ 24.470] 124132537 > >The other position provided: >FEN: r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - >Counting width of legal tree, 5 plies deep... >Time (user) = 41.12 sec >dep #nodes quot sum nodes > 0 1 [ 0.000] 1 > 1 48 [ 48.000] 49 > 2 2039 [ 42.479] 2088 > 3 97862 [ 47.995] 99950 > 4 4085603 [ 41.749] 4185553 > 5 193690690 [ 47.408] 197876243 > >At least, we agree on the resulting numbers :-) > >Cheers, >Heiner
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.