Author: Robert Hyatt
Date: 10:23:41 07/30/03
Go up one level in this thread
On July 30, 2003 at 02:16:24, Uri Blass wrote: >On July 29, 2003 at 23:53:46, Robert Hyatt wrote: > >>On July 29, 2003 at 22:44:28, Vincent Diepeveen wrote: >> >>>On July 29, 2003 at 21:43:11, Keith Evans wrote: >>> >>>>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. >>> >>>you are making a mistake. >>> >>>you still do not understand what perft is. perft is a number >> >>Vincent, you need to shut up here. >> >>Perft is _not_ just a number. It is the _size_ of a tree searched to a fixed >>depth, from some specific starting position. There are _no_ transpositions in >>some programs. But all programs _could_ use the hash table if they wanted to >>avoid generating/tallying a part of the tree that is reached via a >>transposition. >> >>But you _totally_ miss the point. Perft is _not_ a performance benchmark. It >>is a _correctness_ benchmark. As usual, you try to corrupt something and use >>it in a way it was _never_ intended. I'll be happy to enter a "perft war" >>with you if you want. There are plenty of tricks to make mine go faster. But >>that wasn't why I wrote it, and it is why I haven't tried to make it faster. >> >> >> >> >>> you can get it >>>faster by adding hashtables and such. it has nothing to do with generating semi >>>legal or legal moves at all. it is just creating a number faster. and it's not >>>only hashtables. ever thought of how you can speed up perft incredible by using >>>an incremental attacktable? >>> >>>There is no need to generate *any* legal move at all for perft. >> >>Sure there is. Perft defines a tree for a specific position and search >>depth. If you don't generate moves and update the board with them, how >>are you going to enumerate that tree and determine its _exact_ size??? > >You need to generate moves but in the last ply you need only to count them. >I think that vincent means to the last ply when he says that there is no need to >generate any legal move. > >Uri That makes no sense to me. You have to generate moves to produce the tree. He seemed to be saying this wasn't the case. Of course, in his rambling style, who knows what he is trying to say...
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.