Author: Keith Evans
Date: 18:43:11 07/29/03
Go up one level in this thread
On July 29, 2003 at 20:41:37, Vincent Diepeveen wrote: >On July 29, 2003 at 18:18:31, Keith Evans wrote: > >>On July 29, 2003 at 17:35:01, Vincent Diepeveen wrote: >> >>>On July 29, 2003 at 17:14:52, Keith Evans wrote: >>> >>>>On July 29, 2003 at 17:04:44, Vincent Diepeveen wrote: >>>> >>>>>On July 29, 2003 at 16:13:19, Keith Evans wrote: >>>>> >>>>>>On July 29, 2003 at 16:00:20, Tord Romstad wrote: >>>>>> >>>>>>>On July 29, 2003 at 12:49:49, Keith Evans wrote: >>>>>>> >>>>>>>>You're perft performance seems pretty decent to me. >>>>>>> >>>>>>>Indeed. I just did a similar test with my own program on a Pentium 4 2.4 GHz. >>>>>>>In the position after 1. e4 e5 2. d4 d5, my program generates 30 million moves >>>>>>>per second. I guess I could speed it up somewhat, but I don't think I would >>>>>>>come anywhere close to the speeds reported by Vincent and Angrim. >>>>>>> >>>>>>>My move genererator assigns all moves a move ordering score, and also >>>>>>>determines which moves are checks. It generates legal moves only. >>>>>>> >>>>>>>But anyway, I don't understand why people spend so much time and energy on >>>>>>>micro-optimising their move generators. Despite my slow movegen speed, my >>>>>>>program spends only 1 or 2 percent of its time in the move generator. I >>>>>>>guess most other programmers have similar numbers. >>>>>>> >>>>>>>Tord >>>>>> >>>>>>I'm personally interested in the performance of the move generator in a hardware >>>>>>chess chip where it is a large percentage of the total cycles. If it were only >>>>>>1-2% of the time then I wouldn't be interested. Of course a hardware move >>>>>>generator can generate millions of NPS when only running at say 30 MHz, so it's >>>>>>a totally different animal than a software generator running on a 3 GHz >>>>>>processor. >>>>> >>>>>hardware doesn't work like that. you cannot store the moves. >>>>> >>>> >>>>Huh? (Duh?) Where did I say that it pregenerates and stores the moves? Of course >>>>it generates them incrementally. >>> >>>but i hope you realize how hard it is to order moves when all you have is 1 >>>bound that gives how far the incremental generation is. >>> >>>but if you compare speeds. >>> >>>Say that each move costs 1 clock. that's 30 million moves a second at 30Mhz >>>right? >>> >>>Brutus ran at 2002 WCC at something like 33Mhz. So that's 33 MLN a second. >>> >>>DIEP i generate way more than 33MLN a second at the 1.6Ghz K7 i had back then. >>> >>>At 2.127Ghz it is about 72MLN. this with slow RAM storage. It's probably >>>relatively faster at a P4 generating moves because of the fast L1 cache there >>>and everything runs within trace cache when doing a loop for a few millions of >>>times. >>> >> >>Can you do perft at 72 million NPS? (Actually traverse a tree?) If not then >>you're quoting something different. You could use Chrilly's 7 cycle/node number >>which should include everything to generate, make, and unmake moves. So at 33 >>MHz that would be 4.7 MNPS. > >please do not compare perft with generating moves. > > >perft is generating a NUMBER. not moves. > >do you understand? > >all you need is a number for perft. not moves. If you time perft then you get a node count and a time in seconds, therefore you can get nodes per second out of it. If you want to measure correctness then you can just compare the node count. If you want some measure of performance then you obviously look at NPS. I think that this is obvious. Just search through the CCC archives and look for people trying to optimize the NPS in perft. Not that I'm recommending optimizing for that, but it's been discussed many times. My opinion is that if you're going to quote 72 million NPS in software and try to compare that to a hardware implementation, then the easiest way is to compare using a perft style test. If you're just setting up one position and generating moves from that position repeatedly in a tight loop, then there's really no way to compare that. Plus my belief is that the perft number is more representative of the performance of the move generator under real conditions. Here's some perft output from crafty which I take to be the de facto perft standard: Crafty v19.3 White(1): perft 5 total moves=4865609 time=1.24 So to convert this to NPS 4,865,609 [nodes]/1.24 [seconds] = 3,923,878 [nodes/second] Please explain why that is incorrect? What does diep get for this case? 73,000,000 NPS? I find that hard to believe. (Let's assume that hash tables aren't in the picture, because that would mean that you're not really measuring the performance of the move generator. Also maybe there's a small chance that doing something like that might mask a problem in somebody's movegen if they are using perft as a measure of correctness.) -Keith
This page took 0.01 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.