Author: Vincent Diepeveen
Date: 10:42:25 09/06/02
Go up one level in this thread
On September 06, 2002 at 10:54:04, Robert Hyatt wrote: >On September 06, 2002 at 09:18:42, Vincent Diepeveen wrote: > >> >>There is 2 speedups >> a) number of nodes a second. We do not discuss this here >> b) how much faster a program runs compared to a single processor. >> >>We do not discuss a) a lot. In fact a) is something bob doesn't print >>at all at every ply. He prints it after a search. >> >>We discuss here about actual speedup b) : >> > >+I+ discuss actual speedup. _you_ brought up the NPS question, not me. >I don't consider NPS very interesting, other than as a "measure" of how >fast things are going overall. obviously. single cpu it gets a million nodes a second here. dual it'll never get far above 1.5 million nodes a second. 1.6 perhaps. Of course all programs have more problems with dual AMDs here but considering it is single cpu so much faster and cheaper than all other smp processors it means in short it is interesting to tune for it too. >>So 4 processors quad xeon 550 is compareable for bob with >>a 2.8 times single cpu 550Mhz Xeon. >Or, according to the data I sent you via email, 4 processors quad xeon 700 >is 3.0 times single cpu 700mhz xeon. But of course you are not going to ever >use that number. And I call this "cherry picking". You have several >observations. You _could_ average the two and say 2.9. But you didn't. You >could give both, because you have both, but you didn't. You pick the worst one. >And that is fraud itself... Most researchers use testsets to measure speedup. If you are the first one to run an entire game, then the speedups which all other programmers give nowadays are not comparable with yours. The 2.8 speedup was from different positions, just like my own measurements are done too at such different positions. We want a good compare to other programs. If you get a crafty speedindex of 100 and i get a diep speed index of 90, without the 2 numbers being comparable then it is a joke to write them down. Perhaps i should define the 'diep index' as being speedup number times 2. So please compare the same things. You get 3.0 for 24 positions which are all within the same game. Of course that's interesting in itself and much better than 2 positions at a BK testset, but then i say interesting because it is a bigger quantity of positions. What we need is an objective compare between speedup numbers. If we can agree upon that, then we can only make then the next step. Right now your numbers are speedups measured in a way no one else is doing it! And with regard of cray blitz it's even worse, it's with a loaded hashtable even. That's even more horrible. >> >>>3. Is 2. or 1.97 a factor of time, NPS or what? >> >>>4. This split at the root thing, such a refinement I know from forest sciences, >>>but here, what does it mean, and most of all, how many chapters of CC I'm away >>>before I could understand such a term? And how does this topic influence the >>>question of magnitude of advantage through processor number? You see how >>>confusing that is... >> >>The idea is simple. All processors do their part of the >>job in searching the tree. You'll never understand how >>it actually is working unless you do it yourself. > >I don't think "writing one" is an absolute prerequisite to "understanding >one." I believe _several_ here are now beginning to understand many of the >issues I have discussed in the past (such as non-repeatibility, variability, >etc) without having _written_ a parallel search. > >teaching is what I do. If you have to fly before you can understand flying, >then modern aviation must be based purely on myth. > > > >> >>> >>>I'm the real ignorant here and I still have the guts to admit it and to ask >>>these questions. Simply because otherwise I could never hope to improve. >>> >>> >>>Thank you! >>> >>>Rolf Tueschen >>> >>> >>> >>>> >>>>that's a lot more than a run on 1 position. > >So is all the data I post here, including that from last night. I don't >believe half of the stuff you say is supported by _any_ data, myself. >Because your claims _never_ hold up when I test them. There is a conclusion >to be formed from that... > > > > >>>> >>>>>On September 04, 2002 at 14:02:54, Vincent Diepeveen wrote: >>>>> >>>>>>On September 04, 2002 at 12:43:37, Robert Hyatt wrote: >>>>>> >>>>>>Please run crafty at 16 processors. Fine with me. >>>>>>Even though it's a different program. I have no problems >>>>>>with it. >>>>> >>>>>And what would be the point? I might give you some 16 processor >>>>>numbers on a NUMA machine before long. I _might_. >>>>> >>>>> >>>>>> >>>>>>But rewrite also the article then that it's not a DTS thing, >>>>>>but a smp_lock thing that doesn't scale above 8 cpu's. >>>>> >>>>> >>>>>Vincent, the smp_lock thing doesn't hurt me thru 16 cpus as I already >>>>>know. I don't understand why you don't follow this, but in a typical >>>>>3 minute search, I see numbers like this: >>>>> >>>>> time=3:29 cpu=399% mat=0 n=303284136 fh=89% nps=1450k >>>>> ext-> chk=4663926 cap=1175890 pp=230533 1rep=74539 mate=3299 >>>>> predicted=2 nodes=303284136 evals=99342268 >>>>> endgame tablebase-> probes done=0 successful=0 >>>>> SMP-> split=774 stop=133 data=14/64 cpu=13:55 elap=3:29 >>>>> >>>>>That is from a real game played on ICC. >>>>> >>>>>Note it only did 774 splits. that is 774 smp_locks. Do you _really_ think >>>>>that hurts performance? _really_? >>>>> >>>>>If so, I have this bridge I need to get rid of... >>>>> >>>>>You can say smp_lock is a problem all you want. You can say that it killed >>>>>you on a NUMA machine all you want. But that doesn't mean it kills _me_ >>>>>on 8 or 16 processors... >>>>> >>>>> >>>>>BTW I would hate to publish 16 cpu crafty numbers, because that would probably >>>>>give you _another_ problem to overcome with your "sponsors". :)
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.