Author: Vincent Diepeveen
Date: 08:41:39 06/19/01
Go up one level in this thread
On June 19, 2001 at 00:46:25, Robert Hyatt wrote:
>On June 18, 2001 at 19:06:05, Vincent Diepeveen wrote:
>
>>
>>This is utterly nonsense
>>
>> a) their hashtable was already filled
>> b) first 30 seconds or so they search from parallel viewpoint
>> very inefficient. First 10 seconds or so they can only
>> get a few processors to work efficiently together, only
>> after perhaps a minute all processors slowly are working a
>> bit efficient.
>> I already have this problem for 4 processors, Zugzwang clearly
>> had this problem. etcetera.
>
>
>_you_ might have this problem. I don't. I will be quite happy to
>post some speedup numbers for 1-16 processors with Cray Blitz, where
>the search time limit is 1 second max. And that speedup is no different
>than the speedup produced for 60 second searches. Ditto for Crafty, which
>you can prove easily enough.
a) cray blitz is having shared memory
b) cray blitz is using nullmove (even though R is smaller as a few)
c) you don't have cray blitz source anymore, when i asked after it
some time ago you said you lost it.
d) crafty blitz isn't using 16 hardware processors at each general cpu.
both you and i know that a single cpu can't split itself and give
16 hardware cpu's over a dead slow bus (with huge latency that is)
16 commands at the same time.
What a single processor had to do with DB was to get a position and
then put somehow 16 processors to work.
So there is a double splitting problem. First the normal split problems
which at 30 processors is quite solvable as we both know, and you're
offering to show now with something which you said you didn't have anymore
that it's solvable!
Secondly there is the problem that a single processor needs to efficiently
split the tree it searches for 16 hardware processors.
That's pretty hard to do :)
20% total speedup out of 480 processors at a 3 minute search is
hard to improve then!
It's a *very* good speedup.
If you run software on 480 processors i doubt you get to 20% speedup.
OF course that's with cray blitz and other programs. As soon as you
search with a very stupid branching factor getting 20% speedup is
possible to get.
So *somehow* there it lost from its 200M nps 80% speed. It's not
hard to imagine where. Near the leaves. Each leaf being a 6 ply
search without hashtable, so the only position where it can split
is the leaf position. If that position is giving a beta cutoff,
too bad for 15 other processors! You get an actual speedup of 1/16
then!
The problems are easy to imagine.
Best regards,
Vincent
>
>
>> c) crafty has an even better branching factor when it is
>> searching in the same way as Deep Blue, as deep blue had.
>> When crafty dies because of extensions, then prob DB too,
>> but the searches were simply too short (3 minutes at most)
>> to show this. Also older The King versions simply die
>> because of extensions and fullwidth search after it gets to
>> around 6 ply fullwidth search depths (same depth as which
>> DB got). Diep also had the same problem in my tests. You simply
>> die around 11 to 13 ply fullwidth. Extensions completely blow up
>> the tree then.
>> There is too little data to suggest DBs branching factor was good.
>> I never saw outputs of hours of them. Just calculate the error
>> margin. First few ply get quick out of hashtable (because of
>> better sorting), more processors start to join the search tree).
>> So in short there is no way to base your conclusion upon, whereas
>>
>> Both me and Uri have given loads of proof, insight that the opposite
>> is true!
>
>
>
>You say "first few ply out of hash table" but then you say "they can't hash in
>last 6-7 plies which is killing performance." Which is it? It can _not_ be
>both.
first 6 ply are in hashtable of a search. so if i make a move
then still 5 are left.
>But we can solve this easier. Lets take the first move out of book for all 6
>games. And compute the branching factor for those. No hash there.
openings position is the most dangerous position to draw conclusions from.
If you would have studied the log files you would have known that already
at game start they start to search. So at move 1 they already search.
They don't start to search first move out of book.
So that's not relevant here.
First move out of book is not relevant at all. They didn't clear hash
of course. You don't already search at move 1 if it isn't giving a speedup.
I am considering using the same aproach with diep, because when being
parallel it's important to get some things out of hashtable as then you
can put the both processors quicker to work, where now the parallel speedup
first 20 seconds of diep is horrifying. To get from 1.2 to 1.8 takes
half a minute!!!!!
Lose that much in overhead that to get near to 2.0 takes
up to 5 minutes sometimes.
Now if i would have 480 processors, then it's even more important to
quickly get processors to work. So having a few ply out of hashtable then
which directly then can put a bunch of processors to work, instead of
only 16 (Young brother wait, probably heard of it?), then i would
go for that too.
>
>
>>
>>>Knowing that, how can you compare the two? Answer: you can't... not without
>>>a lot more information that we simply don't have..
>>
>>What i know is that DB 100% sure had no hashtable in hardware search.
>>This is so easy to proof.
>>
>>What i know 100% sure is that i completely outsearch deep blue at 3 minutes
>>a move, both positionally, strategically, perhaps only tactical it sees the
>>same.
>
><sigh>..... Perhaps one day you will get to tangle with DB Jr and we can
>put this nonsense to rest, once and for all.
Well i already know from outputs of DB jr during kasparov-kramnik that
i'm tactical hell stronger as that toy thing.
I forgot of course how many hardware processors DB jr used in those
analysis. 1?
Anyway, being tactical strong is not the issue here, except that i
can proof with induction that i win if i'm ALSO tactical stronger.
>
>
>>
>>Perhaps i'm tactical not much stronger, it seems they extend a load of things
>>first few plies. But if my new machine arrives (dual 1.2Ghz K7), then
>>i'm pretty sure i'm tactical also stronger as DB.
>>
>>This is however *so hard* to proof, that it's irrelevant for the discussion.
>>
>>Objective analysis of strong chess players indicate clearly that DB made
>>huge amounts of bad moves, where nowadays chessprograms do not make
>>the same mistakes. the good moves all get reproduced too by the same
>>programs.
>>
>>'saving your ass' nowadays programs are very good at when compared to 1997.
>>
>>In general the weakest chain which programs had in 1997 is completely
>>away.
>>
>>I think it more than logically that *everything* on DB sucks when using
>>todays standards. Just like everything on todays programs will suck
>>when compared to DIEP version 2004.
>>
>>Schach 3.0 from 1997, in those days the tactical standard (nullmove,
>>hashtable, singular extensions, etcetera), i'm tactical outgunning
>>it *everywhere* and on nearly *every* trick.
>>
>>It's branching factor sucks.
>>
>>What we all forget in all these discussions is that in 1997 i was
>>laughed to hell in rgcc especially when i said that branching factors
>>could be getting much better above 10 ply when using nullmove and
>>loads of hashtables.
>>
>>it was even posted that getting a branching factor of under 4.0 would
>>be *impossible* by a guy called Robert H.
>>
>>With 200M nodes a second and a search depth of 11 to 13 ply with
>>a load of extensions and with an evaluation considering at least
>>mobility a bit (DB clearly did a simplistic count on how many squares
>>a queen occupies for example), 11 to 13 ply was *GREAT* then.
>>
>>Especially knowing the design of the chip wasn't done in 1997 but
>>the years before that.
>>
>>Now we are all USED to nullmove. Used to big hashtables.
>>Both things DB lacked.
>>
>>Logically we outclass it by todays standards now.
>>
>>Just for fun someone might want to do a match.
>>
>>rebel 8 at a 200Mhz MMX machine (which was the fastest hardware for
>>Rebel available start of 1997, K6 only was released later that year)
>>versus a top program of today at 1.33Ghz.
>>
>>Of course both using the books of that date they were released,
>>so rebel usin gthe 1997 book, and the todays program using the todays
>>book.
>>
>>Of course all games 40 in 2 level. Other levels are no fun and will be
>>of course an even clearer walk over.
>>
>>I can tell you even a funnier story. Jan Louwman had matched diep against
>>nimzo 1998 with the 98 book. both k7-900. 3 hours a game.
>>
>>*complete* walkover.
>>
>>in 1998 nimzo98 was the best program at SSDF list, not world champion,
>>but definitely one of the stronger programs.
>>
>>Played at todays hardware it gets completely destroyed by todays
>>software.
>>
>>in 1997 and 1998, outsearching the opponent still dominated the
>>commercial programmers. quality at other terrains was not so relevant,
>>relatively seen.
>>
>>Now a program must be strong *everywhere*.
>>
>> - good book (so for example either playing 1.e4 well prepared or
>> never playing 1.e4)
>> - good development of pieces and quick castling (shredder!!!)
>> - reasonable buildup in middlegame
>> - good endgame
>> - EGTBs
>>
>>And during the play no weird things in pruning which cause weird scores
>>to get backupped to the root.
>>
>>So the search must be very 'pure' and not disturbed.
>>
>>In 1997 the common believe of most scientists in rgcc was that nullmove
>>was very dubious. Of course most programmers already believed in it.
>>
>>Some simply couldn't believe in it, as their search was build upon pruning
>>and fullwidth search.
>>
>>One of them simply skipped all those pruning problems (which would
>>have taken another 10 years of design) and searched 11 to 13 ply fullwidth.
>>
>>Can't blame him for doing that.
>>
>>But what was wise to do in 1997, is now of course completely outdated.
>>
>>Best regards,
>>Vincent
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.