Author: Slater Wold
Date: 22:52:04 11/20/01
Go up one level in this thread
On November 21, 2001 at 00:30:15, Robert Hyatt wrote: >On November 20, 2001 at 21:58:57, Slater Wold wrote: > >>On November 20, 2001 at 21:50:32, Uri Blass wrote: >> >>>On November 20, 2001 at 15:37:39, Slater Wold wrote: >>> >>>>On November 20, 2001 at 11:25:50, Gordon Rattray wrote: >>>> >>>>> >>>>>[snip] >>>>> >>>>>Thanks for the helpful info! >>>>> >>>>>>This is the speedup I see: >>>>>> >>>>>>Crafty 1.89x >>>>>>Junior 7 1.81x >>>>>>Deep Fritz 1.31x >>>>>>Deep Shredder 1.81x >>>>> >>>>>This is a surprising and disappointing efficiency for Deep Fritz. So, when >>>>>playing on ICC, do you consider Deep Junior 7 to be your strongest option? I'm >>>>>assuming that if you have, e.g. Gambit Tiger, then Junior's SMP capability will >>>>>give it a significant edge when using your dual, since GT is non-SMP. >>>>> >>>>>Gordon >>>> >>>>I thought so too. Deep Fritz SMP code is broken somewhere. That's why I >>>>laughed when I heard it was going to be on an 8-way box. It would have run like >>>>crap. Unless Frans fixed it. >>> >>>The question for the match against kramnik is the speed up that they get on long >>>time control and not in blitz. >>>I do not know how people got the numbers of speedup for Crafty,Fritz ,Junior and >>>Shredder >> >>A 900mhz 8-way box is not going to be impressive with DF. Not the NPS anyway. >> >>And those are all MY numbers. Run on my 2x1.4Ghz. >> >>>I think that the way to compare is comparing times and not nodes. >> >>I know it's not. You can *NOT* compare solutions with SMP machines. The >>branching is SO random, and so unpredicible, that I have found solutions in 10 >>seconds and not been able to find the same solution in 10 hours. It's the >>beauty of SMP. >> >>>You need to take a test suite from positions when the program changes it's mind >>>after some minutes and comparing times. >> >>No. Won't prove anything. Say it takes 10 minutes to find on 1 CPU, it might >>take 30 seconds to find on 2 CPU's. >> >>>If the numbers are not based on similiar test then my opinion is that they mean >>>nothing. >> >>They were based on something. Program A does 1M nps with 1 CPU. Program A does >>1.81M nps with 2 CPU's. That means Program A's speedup is 1.81. > >No..No..NOOOOO! > >NPS has _nothing_ to do with speedup. Here are three example runs... > > >1cpu: time: 53 nps: 328K >2cpu: time: 28 nps: 626K >4cpu: time: 16 nps: 1162K > >if you use time to compute the 2/4 cpu speedup, you get > >1.89 for 2 processors >3.31 for 4 processors > >if you use nps, you get > >1.90 for 2 processors >3.54 for 4 processors Well, for all intended purposes, that's not really a *major* difference. But I believe you. I will do it this way from now on. :) >NPS is the wrong thing to use because an SMP program will _always_ search >more nodes than a pure sequential program for a given position, except for >rare anomalies. IE on a machine with no memory bandwidth bottleneck, Crafty's >NPS is roughly 4X faster with 4 cpus, but it averages just over 3x faster if >you look at the clock to see how long it takes to find a key move at a specific >depth, or how long it takes to complete a search to a specific depth. > >Ignore NPS and _only_ use the time to solution or time to depth to compare >speeds. Anything else will produce wildly wrong numbers. > > >> >>>Testing it takes time and you need at least some hours of testing before getting >>>an estimate for the speedup (not in blitz). >> >>These were SEVERAL SEVERAL tests I ran. Positions were usually looked at for no >>less than 1 hour. >> >>>Uri
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.