Author: Robert Hyatt
Date: 06:26:11 11/21/01
Go up one level in this thread
On November 21, 2001 at 01:52:04, Slater Wold wrote: >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. The 4 processor test is significant. But even worse, I only ran one position one time for the above. There are positions that produce almost 4x the NPS but only a 2.5X speedup in terms of time. This is called "search overhead" (searching nodes in the parallel search that would not be searched in the sequential search.) > >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.