Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Crap statement refuted about parallel speedup

Author: Robert Hyatt

Date: 22:03:05 09/24/01

Go up one level in this thread


On September 24, 2001 at 22:37:37, Vincent Diepeveen wrote:

>On September 24, 2001 at 09:19:57, Robert Hyatt wrote:
>
>>On September 23, 2001 at 18:32:50, Vincent Diepeveen wrote:
>>
>>>
>>>The average test done here at CCC is 10 to 20 seconds a move.
>>>
>>>Even the new try to make a WACII the dudes test at most at 1 minute
>>>a move.
>>>
>>>So you're kind of wrong here.
>>
>>
>>
>>You are mixing apples and oranges.  The tests here have _nothing_ to do with
>>trying to measure SMP efficiency.
>
>it has, at 1 minute a move my speedup is not even close to 2.0
>
>it's more like 1.6 to 1.8
>
>>
>>>
>>>Most tests in ICCA and advances in ICCA are based upon anything under or
>>>equal to 8 ply.
>>
>>Again apples and oranges.  _most_ ICCA and ACCX articles are pretty old when
>>you look for ones dealing with parallel search.  The older the article, the
>>shallower the depth.  If you find by DTS article you will not find _it_
>>based on shallow searches.  In fact many of the single-cpu searches took
>>_hours_ to run because the 16 cpu tests took minutes for each position.
>
>Yes and you claimed a 2.0 speedup at 2 processors. Pretty impressive
>considering the time when you wrote the algorithm, and in assembly!



what does the speedup have to do with the "time I wrote the algorithm?"

Read my Ph.D. dissertation.  good speedups are easy on worst-first move
ordering searches.  They are easy on best-first move ordering.  They are not
easy on normal chess-engine tree ordering...

that is independent of time or anything.  The old Cray's (C90 that I used in
the JICCA paper for example) is as fast as anything today...




>
>>
>>
>>>
>>>I can only remember a single article 'crafty goes deep' where some
>>>deeper searches were done.
>>>
>>
>>
>>
>>Find the DTS article.  It had deep searches.
>>
>>And please don't start the "but Cray Blitz didn't use null-move R=3"
>
>You got 2.0, i get 2.0.
>
>Now you say i'm big shit somehow.
>
>Why?
>
>Note that the statement that i could do things on 1 processor quicker then
>i can proof incorrect. If you can do the same thing which you do on 2
>processor but now on 1 processor, then that would implicitly mean that
>2 processors are deterministic. Because behaviour at 1 processor is
>deterministic for me.
>
>At 2 it is not. So i cannot do what i do on 2 processors in one process.
>
>How's that?
>
>>and such nonsense.  I'll be happy to show you that the parallel speedup in
>>Crafty is 100% independent of null-move usage.  I can turn it off totally,
>
>Crafty is recursive Bob. You keep splitting at the wrong points too,
>i have no idea what kind of difference that shows, more interesting is
>if you can get cray blitz alive again and run it for my part at an old
>cray but then with R=3 , no singular extensions and futility turned off.
>
>the interesting thing which you also didn't write down in your articles,
>probably because of space is the speedup you get at the different depths.
>
>speedup at 8 ply, 9 ply, 10 ply, 11 ply , 12 ply etc.
>
>To see a graph of it.
>
>>use R=1 (or with a simple source change make it non-recursive R=1 just like
>>CB) and produce some parallel speedup numbers.  The speedup is independent of
>>null-move although the overall search depth shrinks as expected.
>
>>Old SMP articles are not junk.  If I were going to criticize _any_ SMP issues
>>that have been reported, it would be anyone that claims that a speedup of > 2.0
>>is possible, while talking about how his move ordering is better than anybody
>>else's.  It simply isn't possible for _both_ of those conditions to be true.
>
>The difference is i never claimed it to be non improvable. You did a few years
>ago though. You were not the only one saying it was hardly improvable.
>
>>One or the other, maybe.  But a speedup > 2 means big problems in the non-
>>parallel search.
>
>
>>
>>
>>>>
>>>>>  Now, if that improvement isn't made, then you're testing a good
>>>>>>parallel implementation against a poor sequential implementation, so your
>>>>>>speedup value is meaningless.
>>>>>>
>>>>>>Dave
>>>>>
>>>>>The speedup value is not meaningless because it is possible that the cutomer
>>>>>need to choose between poor sequential implementation and good parrallel
>>>>>implentation so from the customer's point of view it may be important to know it
>>>>>before deciding if to buy a machine with more processors.
>>>>
>>>>Parallel speedup is a scientific concept, used when reporting analyses of
>>>>parallel search performance.  What form of product is shipped to a chess
>>>>software program customer is quite irrelevant.
>>>>
>>>>Dave



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.