Author: Vincent Diepeveen
Date: 01:44:18 07/08/05
Go up one level in this thread
On July 08, 2005 at 03:15:26, Tony Werten wrote:
>On July 07, 2005 at 15:43:03, Dann Corbit wrote:
>
>>On July 07, 2005 at 15:01:26, Dann Corbit wrote:
>>
>>>On July 07, 2005 at 14:51:56, Gian-Carlo Pascutto wrote:
>>>
>>>>On July 07, 2005 at 14:37:19, Dann Corbit wrote:
>>>>
>>>>>On July 07, 2005 at 14:14:36, Gian-Carlo Pascutto wrote:
>>>>>
>>>>>>On July 07, 2005 at 13:56:04, Dann Corbit wrote:
>>>>>>
>>>>>>>On July 07, 2005 at 05:05:50, Gian-Carlo Pascutto wrote:
>>>>>>>
>>>>>>>>On July 05, 2005 at 14:37:46, Dann Corbit wrote:
>>>>>>>>
>>>>>>>>>The logfile does not consider the depth on-chip at the leaves. About 6 plies
>>>>>>>>>more. So consider it really to be 16-18 plies.
>>>>>>>>
>>>>>>>>This is quite simply completely wrong, and contradicts what Hsu and Campbell
>>>>>>>>published.
>>>>>>>>
>>>>>>>>http://sjeng.org/ftp/deepblue.pdf
>>>>>>>
>>>>>>>I read the paper. I was referring to this:
>>>>>>>"This typically results in 4- or 5-ply searches plus quiescence in middlegame
>>>>>>>positions and somewhat deeper searches in endgames."
>>>>>>>
>>>>>>>I did not see the contradiction. Can you please point it out ot me?
>>>>>>
>>>>>>The first number in the logs is the combined depth (excluding quiescence, but
>>>>>>nobody counts that). The nominal depth was around 12 ply for the combined
>>>>>>search, not 16-18.
>>>>>
>>>>>Then it represents the estimated maximum combined depth (last column of table
>>>>>2)?
>>>>
>>>>No, that's another matter. Maximum depth is rather meaningless.
>>>>
>>>>Look at Page 5, 1)b) for the statement that the nominal depth is 12 ply on
>>>>average. It's been a while since I read it but basically something like 12 (5)
>>>>meant 12 - 5 = 7 ply software, 5 ply hardware, and then extensions and quiescene
>>>>search.
>>>
>>>It makes me wonder why they got such excellent answers, then.
>>
>>If they could average 100M NPS, then a 3 minute search (40/2 average) would give
>>18,000,000,000 {18 billion} nodes and 36 billion at 200 M (and I seem to recall
>>a theoretical peak NPS rate of 1 billion).
>>
>>Since 6^12 = 2,176,782,336 [assuming a branching factor of 6 for pure
>>alpha-beta with no pruning whatsoever, no null move, and with 36 moves average
>>at each level] a 12 ply search should have taken only 21 seconds at 100 M NPS
>>and 10.5 seconds at 200M.
>>
>>The math does not make sense to me.
>
>Most report a loss of 1 ply of nominal depth for singular extensions (the way
>wich DB was using them) Multiply your numbers with the BF (6 it seems) and they
>do make sense.
>
>Tony
When you have 480 cpu's, and we know on average at most 54 cpu's were used,
it makes more sense that they had major problems to scale up the search from 16
cpu's first few plies to > 54 cpu's (2.5 mln nps per cpu or so).
Their official latest claim is 130 mln nps. That means 54 cpu's.
However we do know they might have mixed old cpu's with new ones, and also cpu's
of different Mhz frequencies with each other. IBM just cared about a higher
theoretical nps. Do you want to play with 480 cpu's and a number of them is old
cpu's?
Whether that rumour from an IBM manager is true or not, is irrelevant now.
They claim 130 mln nps in total and we know their speedup was ugly.
But at 8-12 ply search depths you can expect that first few plies it's very hard
to get more and more cpu's to work.
I've had that effect too in Diep at world champs 2003 when i ran 512 cpu's.
my b.f. there at some points looks like 2.0 which it really was NOT.
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.