Author: Robert Hyatt
Date: 10:26:06 07/30/03
Go up one level in this thread
On July 30, 2003 at 00:34:37, Keith Evans wrote: >On July 30, 2003 at 00:17:38, Robert Hyatt wrote: > >>On July 30, 2003 at 00:09:58, Keith Evans wrote: >> >>>On July 29, 2003 at 23:56:03, Robert Hyatt wrote: >>> >>>>On July 29, 2003 at 23:33:57, Keith Evans wrote: >>>> >>> >>>You're the one that prints out how many seconds that it takes ;-) >> >>Yes, but for a _different_ reason. >> >>If someone wants a perft 8 for some position, and a perft 6 takes 400 seconds, >>I can take a wild guess that I am not going to wait for 8. :) > >Not a bad reason, but you needed a disclaimer in there ;-) > >> >> >>> >>>I don't know of anything else that could potentially be used as a move generator >>>benchmark. Not that one is desperately needed or anything, but I was hoping to >>>compare say Chrilly's hardware performance with some software implementations. >>>If you play by the same unwritten rules then it seems like perft is the closest >>>thing that we have to a benchmark that can measure effective legal move >>>generation rates in the context of making and unmaking moves. >> >>It would not be hard to write one. Let's pick a set of positions, alternating >>with black and white on move. Generate the moves for the first, then the >>second, etc. Do this N times. Time how long it takes. That is all move >>generator, without letting the board and everything just cycle through cache >>over and over with nearly perfect branch prediction, etc. > >The potential problem here is that you then have the overhead of setting up a >new position which is irrelevent for games with long time controls. (Probably >more of a problem for a hardware coprocessor that's sitting on a slow bus where >I would guess that the position setup time would be greater than the move >generation time.) It also wouldn't include the move making and unmaking overhead >would it? And does it address identifying illegal moves? > >Why do you think that this is better than perft? Because you can't "cheat" the >benchmark with things like transposition tables? > >-K Perft basically "walks" a tree. This includes generation, make/unmake. A program that uses "incremental" stuff (make/unmake updates stuff used in the evaluation for more speed) will look slower than one that doesn't. Yet it won't actually be slower overall when the eval (which is not needed for perft) is used in the real search and takes advantage of the incrementally updated stuff to save time.
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.