Author: Robert Hyatt
Date: 21:31:26 11/20/01
Go up one level in this thread
On November 20, 2001 at 23:04:38, Uri Blass 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. > >It means that one position is not enough to get an estimate for speed >improvement > >You can take 100 positions when 1 CPU and 2 CPU get the same move after an hour >of search but 1 cpu needs at least some minutes to find the move(the positions >do not have to be tactical). > >After it you can use the information to get an estimate for the speed up by the >following way(solving mean finding the moves that 1 CPU and 2 CPU like after an >hour): > >1)calculate the sum of the times that one processor needs to solve the 100 >positions >2)calculate the sum of the times that 2 processors needs to solve the 100 >positions >3)get an estimate for speed improvement by dividing the numbers. > > >> >>>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. > >I do not care about this number >I believe that this number should be 2 for crafty because the proccesors always >work in Crafty and the only problem is that in part of the cases both proccesors >search the same part of the tree. > >Uri Not the _same_ parts of the tree. _unnecessary_ parts of the tree. They aren't quite the same.
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.