Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Table statement ** Please a beginner's question for a change

Author: Rolf Tueschen

Date: 11:24:35 09/05/02

Go up one level in this thread


Super answer, you're really a very patient teacher now. As to the "dual" it
wasn't a typo for a change. I was exactly speaking of your "duel", which I think
gives a good description of at least Vincent's mood. Almost a question of
honour. You seem to interprete his style as almost a character deficiency.
Please, don't do that. I would like to see the actual temper still as a result
of his frustration. But then he must talk with the guys from Paderborn who never
had Vincent's success although they had a "Kong" like computer. It's because
Vincent is lacking the usually trained respect in universities he's taking it
from the more sports side. He searched for someone responsible for his mess. If
he only could have known that he hadn't a fair chance to succeed in the first
attempt, the deception would be less great, on the other side perhaps he
wouldn't have worked so hard if he had known all this before.

If I were you I would always prefer his fire than someone similar to a sleeping
pill. You're now on making little jokes and I think after some time you will
surely help him again, at least I would like to see it. Perhaps the whole thing
came by some social reinforcement, because Gian-Carlo had surely almost the same
conclusions, only with less odd remarks. Please give these young men the benefit
of their right to err.

As you could see in my case, this was clear right from the beginning. They
simply couldn't have your experience, and even me as complete beginner in CC but
with other experiences I saw immediately that all that what they had accused you
for couldn't simply be the case.

I find it a bright demonstration  of serenity how you dealt after the first
shock. I think you admit that such errors often give more chances for didactic
success than a silent community. Honestly said, I wished that many more here
would dare to bring forward their very personal results of thinking. Therefore
we should care that Vincent is not treated as the absolute idiot now. He made
mistakes he couldn't omit with his CC knowledge or chess alone but only with the
education in a science. Perhaps this is another task for you when you answer
questions. You already introduce many historical stuff, but also important are
some _logical_ explanations.

Rolf Tueschen


On September 05, 2002 at 13:38:28, Robert Hyatt wrote:

>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.