Author: Robert Hyatt
Date: 10:38:28 09/05/02
Go up one level in this thread
On September 05, 2002 at 11:14:17, Rolf Tueschen wrote: >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. > >1. May I politely suggest to you that you stop this tradition of writing your >new remarks below the top line of the quotes "someone wrote..."? > >2. Here is a basic question from my ignorance and for all the young readers here >who wouldn't ask such questions which prove that someone hasn't understood >something. > >Could either Bob or Vincent explain why sometimes the duel is about below 2. and >then here above even 2.8 should be nothing special following Vincent? We aren't talking about a dual. You have to be very careful when reading Vincent's posts because he jumps around terribly. We are temporarily off the dual topic and on to the "quad" topic. :) > >What is this number standing for is it about the advantage of a n+1 processor >number "over" n? And second, what is the point of significant advantage? Greater >than 2.? And all what is below 2, this is weak progress? Several years ago, I ran a bunch of test positions and posted the results here, after the SMP search seemed to be functioning well, in its more or less final form. I gave the speedups for each of the kopec positions, for 1, 2 ,3 and 4 processors. And then pointed out that the speedup was a good fit to the straight line formed by speedup = 1 + .7 * (NCPUS - 1). IE two processors are 1.7X faster, three are 2.4X faster, and four are 3.1X faster. I have been running tests off and on and have not found any serious deviation from that, although I certainly would not begin to claim that the above speedup is good in all cases, or good in all test sets, or anything of the sort. It has simply fit the results. Sometimes not so well. IE more than one person has run a test set thru crafty and reported 1.9x for two processors, which is _more_ than my simple linear approximation predicts. But I don't change the estimation because of those unless I can see that it is true over a large set. > >3. Is 2. or 1.97 a factor of time, NPS or what? It depends on what vincent is talking about at the time, which changes with the wind. At one point it was in terms of raw NPS. If I search 2x as many nodes, however, I don't necessarily search twice as fast. On other occasions, this would be the actual speedup, independent of the NPS searched. On other occasions it could mean _anything_, if you know what I mean... > >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 this. If you want to do the most efficient parallel search possible, you have to split the work up at positions where you _know_ you have to search every node. If you don't, then you run the chance of searching stuff you would not search in a serial/sequential search. The root of the tree is one such place. Once you search the first move and get a score, you can search the remainder in parallel, with absolutely no overhead of any kind. Because you _know_ they have to be searched. I did this in Cray Blitz for a while, then turned it off for reasons mentioned in the DTS article. I do it in Crafty, but in a hybrid way that gets the advantages of splitting at the root, without suffering thru a lot of the problem described in the DTS article... > > >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. > I don't think the problem will be understandable until you get neck-deep into alpha/beta. Once you do, however, the issues become quite easy to understand and it is then possible to attempt to develop work-arounds for issues you want to address... > >Thank you! > >Rolf Tueschen > > > >> >>that's a lot more than a run on 1 position. >> >>>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.