Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Here are some actual numbers

Author: Robert Hyatt

Date: 21:10:22 04/15/03

Go up one level in this thread


On April 15, 2003 at 09:03:21, Vincent Diepeveen wrote:

>On April 15, 2003 at 04:54:11, Tony Werten wrote:
>
>>On April 14, 2003 at 17:43:12, Robert Hyatt wrote:
>>
>>>On April 14, 2003 at 17:15:41, Vincent Diepeveen wrote:
>>>
>>>>On April 13, 2003 at 22:39:39, Robert Hyatt wrote:
>>>>
>>>>>On April 13, 2003 at 11:49:28, Vincent Diepeveen wrote:
>>>>>
>>>>>>On April 13, 2003 at 11:27:53, Robert Hyatt wrote:
>>>>>>
>>>>>>I said initially. It drops back to 10 splits a second in DIEP after a while.
>>>>>>Search depth matters.
>>>>>>
>>>>>>Let's compare 2 things.
>>>>>>
>>>>>> time=45.98  cpu=464%  mat=0  n=37870294  fh=88%  nps=823k
>>>>>> ext-> chk=638414 cap=249442 pp=9588 1rep=32966 mate=223
>>>>>> predicted=0  nodes=37870294  evals=14565859
>>>>>> endgame tablebase-> probes done=0  successful=0
>>>>>> hashing-> trans/ref=28%  pawn=93%  used=28%
>>>>>> SMP->  split=431  stop=57  data=6/64  cpu=3:33  elap=45.98
>>>>>>
>>>>>>MT 2  crafty 18.10 which i have here. 431 splits at 45 seconds. I guess you must
>>>>>>limit in crafty the number of splits a lot as splitting is expensive in crafty
>>>>>>when compared to the costs of a single node.
>>>>>
>>>>>I'm not sure how expensive it is compared to a node.  I'll run a test where
>>>>>I do the split overhead at every node to compare, however...
>>>>>
>>>>>
>>>>>
>>>>>I don't limit them at all.  The only limit is the YBW algorithm.  But I split
>>>>>at the root also, which reduces them signficantly...
>>>>
>>>>I can split at the root nowadays, but i have turned it off for diep. it gives
>>>>too poor speedup for me. The interesting thing which searching SMP can give is
>>>>transpositions at a big depth which possibly are overwritten by a sequential
>>>>search. i don't want to miss them.
>>>
>>>Maybe you don't split at the root correctly.  I limit this with some intelligent
>>>guesswork, so that if it appears that I might change my mind this iteration,
>>>then
>>>I don't split at the root until I have searched all moves that I think might
>>>replace
>>>the best move...
>>
>>Just trying to understand. Are you talking about the case where the best move in
>>the root got a fail low ?
>
>this has not so much to do with alfabeta but with how you parallel split.
>
>After the best move has been searched (YBW property) so after you have a
>mainline, then the rest of the moves can be searched in parallel according to
>YBW algorithm. Bob is doing that in crafty (with usually 3 moves for the YBW
>property and not 1, as nullmove counts too as a move. I'm using 2, that includes
>nullmove).

No I'm not doing it that way.  I have explained this before.  When I complete
an iteration, I look at the node counts for each root move (I keep them
separately so that I can re-order the root moves based on this node count.)

If any look promising (large node count compared to others) then I search it
before I drop into YBW and search the rest in paralel.  The number of moves I
do this to is not fixed.  It depends on how many root moves produce big node
counts...


>
>I'm not doing that in Diep as it gives me a bad parallel performance. For
>fritz&co it didn't give a good speedup either.
>
>Of course i did mainly dual cpu tests here. not many 16 processor tests. I can
>get a 16 processor NUMA machine for > 90% busy effectively even with 2 cpu's at
>1 position, so no need at all to split at root at all. So no need to try if it
>already gives a poor speedup at 2 processors.

It only gives a poor speedup if you do it _wrong_.



>
>However with 128 processors or so it might be a good idea to re-experiment with
>this as it is hard to get cpu's busy.
>
>Crafty on other hand doesn't have a very good speedup at 2 processors and the
>price of a split is expensive, so probably Bob concluded something else than i
>did.

I'm doing pretty well at 2 processors...


>
>>
>>When that happens, your testresults indicate that's it's better to split lower
>>than to search 2 rootmoves parallel in order to get an established score asap ?
>>( So not breaking off seacrh when 1 gets a first failhigh, but only when the
>>score is resolved )
>
>>Tony
>>
>>>
>>>
>>>>



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.