Author: Robert Hyatt
Date: 10:29:05 09/05/02
Go up one level in this thread
On September 05, 2002 at 10:53:22, Vincent Diepeveen wrote: >On September 04, 2002 at 14:29:05, Robert Hyatt wrote: > >you get even with fast memory on your quad only a 2.8 speedup >on average at 30 positions. I got a 3.0 speedup on the positions you wanted me to run. You have the data, you _know_ that is correct. But only for that one run. GCP got 2.8 on a different machine (quad 550 of mine compared to my quad 700) and I'd expect that if it were to be run again it would produce a different result also. > >that's a lot more than a run on 1 position. You can say that all you want. Doesn't make it true. My SMP test results have _always_ been with respect to many positions when I talk about average speedup and the formula I generally provide. Only an idiot would use _one_ position for anything other than as a counter example if some know-it-all says "you can't get more than a 1.4X speedup". Because _then_ one exception is enough. But for speedup results, I use test _sets_. Ask Bruce. He and I used to exchange results all the time as we were working on our respective parallel searches. And we _both_ used test suites of positions, not single positions. So this is simply more "disinformation" for which you are becoming quite infamous... > >>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.