Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Hsu Presents a Paper at

Author: Robert Hyatt

Date: 14:19:51 06/26/98

Go up one level in this thread


On June 26, 1998 at 05:52:15, Vincent Diepeveen wrote:

>
>On June 26, 1998 at 05:08:22, Roberto Waldteufel wrote:
>
>>
>>On June 25, 1998 at 20:52:40, Vincent Diepeveen wrote:
>>
>>>
>>>On June 25, 1998 at 12:15:09, Robert Hyatt wrote:
>>>
>>>>On June 25, 1998 at 08:07:53, Roberto Waldteufel wrote:
>>>>
>>>>>
>>>>>On June 25, 1998 at 06:35:40, Vincent Diepeveen wrote:
>>>>>
>>>>>>
>>>>>>On June 25, 1998 at 04:54:02, Roberto Waldteufel wrote:
>>>>>>
>>>>>>>
>>>>>>>Here's another question about Hsu's chess chip. I seem to recall reading some
>>>>>>>time ago that Hsu was considering a commercial release of his chip. Does anyone
>>>>>>>know anything more about this? If the chip were to become available, how could I
>>>>>>>use it in conjunction with a PC? would the fixed depth not be "out of sync" for
>>>>>>>the speed of, eg a Pentium 333Mhz if it was designed to work with a
>>>>>>>supercomputer, or can the fixed depth be adjusted to redo the balancing act in
>>>>>>>the new environment? If it were possible, I would be very interested in
>>>>>>>experimenting with this sort of hardware coupling. I assume that it would extend
>>>>>>>the depth to which a program could search by something like 4 extra plies within
>>>>>>>the same time. This would surely improve the strength of the PC ches programs
>>>>>>>quite a lot!
>>>>>>>
>>>>>>>Roberto
>>>>>>
>>>>>>You see it wrong. If you do 4 ply searches without hash etc, then
>>>>>>2.5 million drops quickly to say 300k nodes a second.
>>>>>>
>>>>>>So in fact you're playing against a kind of fritz5, which DOES search
>>>>>>all leafs fullwidth, which gives you some extra tactics, so commercial against
>>>>>>programs which are only tested at the same hardware and are only
>>>>>>busy with outbooking and trying to finish the game by means of tactics,
>>>>>>you beat with big numbers then, but it will play horrible.
>>>>>>
>>>>>>Vincent
>>>>>
>>>>>Hi Vincent,
>>>>>
>>>>>I'm not sure I understand - can you explain what yo mean. I do use hash tables -
>>>>>would not the Chip have access to my system's RAM? And When you say it would
>>>>>play horribly, why so? how could the chip make it play any worse than without
>>>>>the chip?
>>>>>
>>>>>Best wishes,
>>>>>
>>>>>Roberto
>>>>
>>>>
>>>>you have to ignore part of what vincent writes, because he is an "anti-deepblue"
>>>>person from way back.  A couple of key points:
>>>>
>>>>1.  no a chess processor could not see your RAM.  But they do have their own
>>>>hash table memory.
>>>>
>>>>2.  a PC program with one of these chips attached would be far and away stronger
>>>>than any existing computer chess program running on a PC.  A chess board that
>>>>they used had 8 processors n it.  A PC could use the same approach, and search
>>>>at about 20 million nodes per second.
>>>>
>>>>I pointed out to Vincent last week here that he was not doing well playing
>>>>against Crafty.  He pointed out (factually, by the way) that Crafty has a
>>>>hardware advantage with the 4 processor ALR.  But he's going to have to take
>>>>a stand on one side of the fence or the other.  Either speed is important, and
>>>>his note about me having faster hardware does explain why crafty wins most of
>>>>the games played on ICC, or speed is not important and doesn't explain crafty's
>>>>win/lose ratio vs the various DiepX programs on ICC.
>>>>
>>>>I believe in a combination of speed and intelligent.  DB has that.  A PC-card
>>>>with one or more DB processors would *still* have that.  And it would produce
>>>>unheard-of performance figures for a PC-based chess program.  Ala' Deep Blue
>>>>Junior, which is basically a PC with a chess board (actually an IBM single-cpu
>>>>workstation with a VME-bus chess card, so don't start hoping to buy one of those
>>>>and plug it into your PCI bus.  :)
>>>>
>>>>Bob
>>>
>>>You have to ignore most of what Bob writes about Deep Blue, as he is a
>>>known pro-deep-blue authority.
>>
>>
>>If Bob is an authority on DB, then why should I ignore him? I have always found
>>Bob to be a font of knowlege in respect of things to do with computer chess. He
>>has been in conversation with the DB people, he has written his own programs
>>(one of which I believe won the World Computer Chess Championships - can't
>>remember which year though), and I have found his suggestions of great help in
>>the past.
>>
>>
>>>
>>>As i pointed out a 'smart' program like deep blue can never do much
>>>knowledge within 10 clocks. This means that total depth of everything
>>>is 10 clocks.
>>>
>>
>>Now if I understand Bob correctly, all the positional scoring stuff is done in
>>parallel as they did in Belle, so it seems quite possible to me that it's all
>>done in as little as about 10 clocks of a PC's CPU.
>
>you can *NOT* do everything in parallel.
>
>Within evaluation you get *parallel* results, which you put into new
>functions (taking again clocks), which afer a lot of *conditions*
>get into new results.
>
>if pattern
>   then evaluate
>
>But first you need the compare values for the pattern,
>which are from previous functions
>


Vincent, the depth of your ignorance (in some subjects like hardware design)
are only exceeded by the level of your self-assurance that you know everything
there is to know...  Here you don't.

Here's a basic hardware design lecture:

DB is running each chess processor at 24mhz.  Doesn't that seem a little slow
by current standards?  Here's why:  I'm going to round this up to 25mhz to make
the numbers easier.  25mhz means 40 nanoseconds per clock cycle.  Todays gate
delay speeds can be quite easily taken to 100 picoseconds... which means that
one clock cycle on the chess processor can withstand 250 gate delays.  That
means I can take any combinational logic circuit I want, whose tree is 250
deep or less, and execute that in one clock cycle, because all gate delays
will add together and still settle in under one clock cycle.  So I can do
up to 2^250 discrete ands, ors, etc and get away with them in *one* cycle.
After that one cycle finishes, which can compute up to 512 (total) different
things in parallel, I can use the next clock cycle, with another 250 gate
delays, to mix and match, shift, multiply, compare, sum, rotate, and whatever
else I want to do each of those first-order terms and produce 256 second-order
terms.  I still have eight clock cycles to go.  I can now take any combinations
of those 256 second-order terms, do whatever I want to them, and reduce that to
128 third-order terms, in one clock cycle.  Ditto for the next 7 to take this
finally to a single evaluation term.  I don't do anything that complicated in
Crafty, nor do you in DiepX.  Because you can't and search more than 10 nodes
per second.

So don't tell me what you can't do in parallel.  Maybe *you* don't know how to
do it, but *I* do.  I was designing communication hardware when you were just
an itch in your daddy's crotch, to quote a famous movie.  And I was doing this
same sort of stuff.

You obviously have no idea what "clock cycle" means, nor do you have any idea
what "gate delays" means, and with that lack of knowledge, it is hopeless to
try and explain this to you...  any more than I can explain integral calculus
to a 5 year old.




>After all this you get an evaluation which you have to *wait* for
>before you can use them in your search.


*not* if I do it in parallel, and overlap the search... and start the
eval for the next ply right after the makemove for *this* ply.  That's
what you don't (or won't) understand.  You are thinking serially.  At this
rate, parallel Diep has no chance to succeed, until you modify your thinking.


>
>So yes a lot goes parallel, but you cannot do *everything* parallel,
>because things are depending upon each other.
>
>>>Also first Bob wrote that Deep Blue had 1000 adjustable parameters.
>>>As i pointed out 1000 adjustable parameters are hardly more than
>>>piece square tables (already taking 12*64=768 adjustable parameters).
>
>>So you say that full piece-square tables plus about another 232 parameters is
>>not enough? Sounds like plenty to me.
>
>That's not much, especially if you give for example freepawns at different
>squares different bonuses. That already takes care for 64 values.
>
>Further later was claimed that the amount was 6000, which is impossible
>to do in 10 clocks.


only for those with no background in circuit design.  You'd be amazed what  the
pentium Pro processor is doing in *one* clock cycle *internally*.  And I'm not
talking about the 200mhz clock... I'm talking at gate-delay levels...


>
>If i parallellize only evaluation (not taking care for the search where you
>lose clocks too), then i NEVER can do it in parallel in 10 clocks.


and just because *you* can't do it in 10 means I can't?  Seems like sound logic
to me...


>
>No way. I will not make it within 100 clocks even.
>
>Too many things depending upon each other.
>
>>>So when smoke about knowledge has been removed, we can go to
>>>the supposed speed of it.
>
>>>Then it appears that from the few printouts i saw of Deep Blue,
>>>that it just searched 11 or 12 ply.
>
>>>That's not much for a 200 million nodes a second program.
>>>
>>
>>Well, I don't know how deep you would expect it to search, but if I could get a
>>full-width 12-ply search with quiescence searching on top in middlegame
>>positions, I would not grumble!
>
>Buy a PII-300 and see whether you get 11/12 ply in middlegame,
>then look to the 200M nodes DB needs for the same.


Again... if DB used null-move R=2, with a search like mine, they would do 20+
plies in middlegame.  They do extensions instead.  I do 12 plies at 200K nodes
per second.  They are 1,000 times faster... with a branching factor of roughly
2.5, what is log base 2.5 of 1000?  That's my search depth at that speed.  So
*obviously* they are doing something else.  You compare your 12 plies to their
12 plies.  I say that's total hogwash.


>
>>>Now when we consider that it has MASSES of disadvantages a normal
>>>chessprogram has at a general purpose processor, not to
>>>confuse with single chips, then we see after some calculations that
>>>those processors indeed are fast, but their practical speed compared to
>>>PC programs is a lot less.
>>>
>>>Still more than PC programs of nowadays, so no doubt it'll kick some butt
>>>in blitz, but i doubt whether normal users who likes to see some positional
>>>insight
>>>of a program as well will ever be happy with it.
>>>
>>
>>I just want my program to play the strongest possible game of chess I am capable
>>of achieving. Whether the program plays in a positional or tactical style I
>>don't mind, as long as it wins. I have found that it plays best in open,
>>tactical positions, or in positional struggles for controll of open files and
>>central outposts, but not so well in blocked positions. I think most users
>>prefer a tactical program, although my own chess style as a player is more
>>stodgy than my program's style. But then this brings into question what exactly
>>constitutes a *normal* user.
>
>Well what refrains you from developing another pawn grabbing program,
>but be aware when 2 programs which just capture pawns play each other,
>then the deeper searching will always win,
>
>Because your knowledge is a subset of the other program which when
>searching as deep or deeper will always see the same or more.
>
>That's why some see DB as *unbeatable*.
>I don't see it that way.
>
>"Tactics is a very important positional aspect of chess"
>
>>>Further i like to point at the fact that the technology used for DB
>>>chessprocessors is very cheap.
>
>>Great! Where can I buy it?
>
>Meaning to say if IBM would allow the DB team to make a PC version
>this would be not so expensive.
>
>>>The salary of the PR people who were
>>>needed to organize the event needed probably eated up the biggest part
>>>of all that money, which IBM claims that the event Deep Blue-Kasparov took.
>
>>>Greetings,
>>>Vincent



This page took 0.02 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.