Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Go Brutus!!

Author: Robert Hyatt

Date: 06:43:19 11/25/03

Go up one level in this thread


On November 25, 2003 at 04:09:54, margolies,marc wrote:

>Hi Dr. Hyatt,
>Your comments about Brutus beg a question in my mind.--I assume that all your
>facts are correct---
>What is situationally different now which keeps Dr Doninger's current work from
>competing in comparison to past achievements by you with CrayBlitz.(I am
>remarking about your reference to Crayblitz' performance against its
>contemporaries versus Doninger's node speed compared to say Opteron servers)
>You mention current processor speed as a strong factor to outmode his approach.
>are there other issues as well?

Not really.  In general, dedicated hardware solutions offer at _least_ 10x the
speed of general-purpose computer solutions.  And often take that to 100X
faster.  For example, DB in 1997 was doing over 200M and peaking at 1000M nodes
persecond.  In 1997 a PII/300 was a good box, probably producing somewhere
around 100K nodes per second.  So a factor of about 1000X for DB.

That's compared today to a single board doing 2.5M. Remember that Fritz vs
Kasparov was doing nearly 4.0M on a quad xeon.  Crafty on a quad opteron is
doing nearly 7M and that is on 1.8ghz opterons where 2.2's are shipping today.

The speed advantage is simply not what it used to be in the case of first Belle
and then DT/DB.  It is nothing to sneeze at, of course, but it is not something
that particularly strikes fear into me, wondering how to compete with it.

>Would these issues be characterizable as technical in nature like the 'overhead
>' involved in managing the distribution of the workload--OR---
>does it boil down to some sort of RISC/CISC argument in the sense of being an
>archietecturally inapropriate remedy to the problem of chess evaluation?
>Of course I would ask more but I understand so little really -- and would not
>appear to try to put words in your mouth.

There are several issues.  A PCI card is not particularly efficient, because
the PCI bus is so incredibly slow compared to the clock speed of the actual
microprocessor.

It takes a significant amount of time to migrate something from software into
a FPGA implementation.  During that migration, GP computers continue to get
faster.  So you had better start off with parts that have a significant speed
advantage, because by the time the thing is build, programmed and tested, the
speed advantage is going to slip.  For example, I would try to use an 8-way
opteron box to play against it, giving a speed of something over 15M nodes
per second.  Or a 16-way opteron that should come close to doubling that...

In 1980 when the last Belle box was built, there was _no_ hardware available
that was faster than the Cray-1 we used.  We were doing about 8K nodes per
second to Belle's 160K.  By 1983 when we won the WCCC for the first time, Belle
was still at 160K but we had closed the gap to 20K+ for the Cray XMP-2.  By 1984
we were running on a 4-processor machine that was doing 80K.  And by 1988 we
were going over 200K on the Cray YMP-8.






>Thanks.
>
>
>
>On November 24, 2003 at 18:31:10, Robert Hyatt wrote:
>
>>On November 24, 2003 at 18:03:41, Pete Rihaczek wrote:
>>
>>>On November 24, 2003 at 16:14:12, Robert Hyatt wrote:
>>>
>>>>>I don't think it is _that_ revolutionary.  IE a single FPGA board and
>>>>computer together search about 2.5M nodes per second, according to comments
>>>>by them when we have played a few skittles games on ICC.  A dual-CPU opteron
>>>>is faster than that, as a reference point.
>>>>
>>>>yes, I know that he is running with four machines, two FPGA cards per machine
>>>>in Graz.  But then again, 8-way opterons are around as well.  I'm hardly
>>>>"anti-hardware" but the benefits to using hardware normally far-surpass
>>>>readily available general-purpose computers.  IE belle did 160K when the
>>>>fastest competitor was 20K (Cray Blitz).  Deep thought went to 1.5M when we
>>>>were at 200K with the fastest hardware Cray had at the time.  The FPGA
>>>>approach doesn't have that significant speed advantage.  IE a single card
>>>>at 2.5 M nodes per second is within reach of a single processor machine
>>>>today...
>>>
>>>Perhaps, but when DB2 beat Kasparov, the question was asked, if doing eval in
>>>hardware is so good, why not create a hardware card for your PC that does it?
>>
>>Let me be _CLEAR_.  I am _not_ knocking this idea.  I simply said that it is
>>not nearly so impressive the third time around.  Belle was the first, and
>>it was a factor of 10x faster than the nearest competitor.  DT did it the
>>second time with a similar advantage.  (Of course DB was totally ridiculous
>>in terms of speed, but it was also very pricey so I have ignored that).  This
>>is the third time a hardware solution has been done, but it is simply not
>>giving that much of a boost to the speed.  If it had been ready 5 years ago
>>it would have been very significant.  In another two years it will be time
>>to do it again...
>>
>>
>>
>>>This is the first successful crack at it. As far as node speed, Kasparov does
>>>2-3 nodes per second. If you could create an eval routine that would
>>>consistently evaluate a position as well as the best human grandmasters, how
>>>many nodes would the computer have to search to always find the best
>>>continuation, at least to the point that it consistently outplays all humans?
>>>The ability to make the eval as complex as necessary without penalty is probably
>>>worth a lot more than speed.
>>
>>I've always argued that point.  That's the point for doing the eval in
>>hardware.  But at 2.5M nodes per second, it simply is not _that_ fast, compared
>>to general purpose machines of today.  That was my only point.  Belle and
>>DT/DB were much more remarkable as _nobody_ could keep up with them on any
>>hardware.  Today there are machines that will outrun the Brutus machine,
>>which is why I made the comment.



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.