Author: Eugene Nalimov
Date: 21:34:01 01/26/00
Go up one level in this thread
On January 26, 2000 at 23:53:49, Robert Hyatt wrote: >On January 26, 2000 at 20:03:56, Peter W. Gillgasch wrote: > >> >>This is what I think too. Even if they have still significant clock >>cycle difference between "cheap" and "expensive" nodes they can overlap >>the first FIND-AGGRESSOR / FIND-VICTIM operation with the slow eval >>cycle. Anyone cares to post the actual cycle counts given in IEEE micro ? >> >>Anyway, I still believe that the argument regarding the fail low q nodes >>is bogus because it assumes that the rate of fail low q nodes after a 10 >>ply full width search plus extensions and a 4 ply hardware search (is this >>a q search only?) > >No. This is a full-width search with extensions, + q-search. It was >basically the same idea as done in the belle machine, except collapsed to >one chip. > > > >> multiplied with the clock cycle difference between the >>slow and the fast eval can differ so greatly that it is not washed out >>by the overhead move generation and tree traversal cycles which are >>probably in the order of 1,1,2,2,2 = 8 cycles for each "cheap" cutoff. > >also remember that this is synchronous logic. The fast eval can give a quick >exit, but it still takes 10 cycles to exit as I understand it. As he was very >specific to say 24mhz processors searched 2.4 M nodes per second exactly. And >his 20mhz procssors searched 2M nodes per second exactly. That tends to say >that the fast eval/slow eval/other stuff are done in parallel and used as >needed... It would be harder to design a piece of hardware that had a variable >number of cycles per node without microprogramming the thing... I don't see why have a fast eval if it is evaluated in the same amount of clocks. Why not use the "standard" one? Eugene >> >>The whole proposition by Ernst implies implicitly that their on chip >>move ordering is all messed up and their slow eval is painfully slow >>compared with the move generation and tree traversal clock cycles. >> >>I don´t buy that. >> >>-- Peter >> >>>This would change if some of this stuff backs up into the software part of >>>the search, of course... But we seem to be talking only about the q-search >>>as implemented in hardware, and every node saved is N nanoseconds saved, period. >> >>Bob I really hate it when we share the same opinion 8^) >> >>>(N is roughly 500, exactly 500 for the 20mhz processors, a little less for the >>>24mhz processors).
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.