Computer Chess Club Archives




Subject: Re: LCT II Fin4, Deep Thought, and Deep Blue (was Re: LCT II results...)

Author: Albert Silver

Date: 17:17:05 01/06/98

Go up one level in this thread

On January 06, 1998 at 17:30:40, Don Dailey wrote:

>>>>Deep Blue sucks??? That isn't exactly what I said, and if that's the
>>>>impression I gave, then I'd like to clarify. You say you turned off you
>>>>endgame databases. Fine, but what does that have to do with knowledge?
>>>Ok, please pardon me, I didn't consider what my words implied.
>>>I asked a question, and if anyone has an idea, that'd be great.  I am
>>>afraid that we'll go straight to the traditional "How good would DB be
>>>vs program X" discussion, where X is Hiarcs, Rebel, Genius, or Fritz,
>>>rather than talking about the issue I raised.
>>Quite possible. Everyone knows that in the Deep Blue project they had
>>the entire backing of IBM and were able to devote as much time as
>>necessary to fine tuning their program, but I don't know what the
>>situation was back then. Bob has often explained how he had had to do
>>all of his debugging smack in the middle of an event because he couldn't
>>just go around tinkering with his Cray program on a Cray whenever he
>>pleased. Maybe they had a similiar problem then, I don't know.
>>>I may be wrong, but I don't think this is a knowledge problem.  I think
>>>straight search finds it just fine.  If DT didn't find it, it raises
>>>questions about their search, or perhaps they simply didn't have enough
>>>time to find it.  It'd be interesting to find out what happened here.
>Hi guys,
>Here is my take on Deep Blue and it's algorithms.  First of all their
>approach is based on lots of hardware which gives them a HUGE problem.
>If something is wrong with our software we quickly fix it.  If something
>is wrong with their hardware they have a huge problem that will take
>months to get to the next version.   So there is a lot of flexibility
>we take for granted that they do not get.  What they have done is very
>impressive indeed and took a great deal of engineering talent.
>As far as the classic question about how would they do against the
>best micro's on equal hardware?   First of all it's not easy to define
>what equal hardware is at all.   But I'll take a stab and give you
>my sense of the issues involved.
>Let's use REBEL as representative of the best software available.
>If you scaled Rebel up to do the same Nodes per second as Deep Blue
>there would be no contest, Rebel would be a HUGE favorite.
>But this is hardly a fair comparison, Rebel is a SERIAL program and
>is clearly more efficient than a parallel program which tends to look
>at many extra nodes to do the same amount of effective processing.
>So let's "pretend" we can run the pure Deep Blue algorithm in SERIAL
>mode and match up both Rebel and Deep Blue, let's say 2 million nodes
>per second (and equal hash tables.)
>The winner?   REBEL wins again!  But we are still being quite unfair.
>Deep Blue is forced to accept compromises and inflexibilities that
>REBEL does not have to deal with.  It's quite certain that many design
>choices were optimized for the exact approach each side was using.
>From Deep Blues point of view, the stuff in Rebel would be wrong to
>attempt to implement in Deep Blue.
>An example of this will suffice.  Until recently Deep Blue could not
>even pick up repetition in the hardware portion of the search.  No micro
>program would dare leave this out, it's a bad idea.  But at the time
>choosing to leave it out seemed right for Deep Blue because it added
>too much complexity to the chips that did the end node searching.
>When we played them in Hong Kong they were quite afraid we might get
>a draw (we did not) because there were long checking lines for us.
>They were noticably disturbed by the possibility.
>Well since then they have corrected this problem but there was no
>easy fix.  It took a complete re-engineering of the chip and probably
>at least a YEAR or more to go through the whole cycle.
>The real bottom line here is that it is almost silly to compare the
>two programs except on absolute strength.   Deep Blue could probably
>not hold up MOST of top micro's if you tried to equalize everything
>in this manner but it's no reflection on the Deep Blue team.   In
>every way (except raw speed) the Deep Blue team is handicapped so you
>can not expect them to compete with the highly tuned micro programs.
>Would you compare a world class human sprinter to a cheetah and say
>how fast would the Cheetah be if it were only human?
>So does Deep Blue suck?   In rating points per node searched, YES.
>In absolute strength of course NOT.  It's unclear (to me) if they
>are much better than the very best micro's but I'm pretty sure it
>would win a long match against any of them (this year anyway.)
>Deep Blue's performance seems to be about as good as the top micro's
>based on the few tournaments it's played in and the close (but very
>short) match against Kasparov is a good indication that it's quite
>Sorry Bruce, I know you didn't want to hear about this!   I carefully
>avoided singing their praises or saying they sucked!
>- Don

I can already see Bruce's look of dismay as he says: "You see? You see?
I told you it would crop up again!" ;-)

Rating points per nodes searched? Somehow that looks very fishy.
Different hardware has allowed different types of programs to be
developped and as far as DB is concerned, it's quite simply impossible
to compare as the software was developped around the hardware. It's not
portable. I think that this kind of comparison is moot so I don't try
it. The software is the hardware and vice-versa. You can't downsize DB
as the program IS the hardware every bit as much as it is the software.
Change the hardware and you don't have DB, you have something else, not
even just the DB software as the software can ONLY exist on that
hardware. I read Shroeder's response as well, and he raises an
interesting point. How to know when the computer chose the best move,
and even when it does and we know it, then how do you know that it can
do it consistently and that it isn't a fluke?

This page took 0.01 seconds to execute

