Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Status of Brutus?

Author: Vincent Diepeveen

Date: 17:59:24 07/28/03

Go up one level in this thread


On July 28, 2003 at 19:16:08, Keith Evans wrote:

>On July 28, 2003 at 16:52:29, Vincent Diepeveen wrote:
>
>>On July 28, 2003 at 16:45:33, Keith Evans wrote:
>>
>>>On July 28, 2003 at 13:36:09, Vincent Diepeveen wrote:
>>>
>>>>Just compare the design of the move generator of Hsu with chrilly. It is a
>>>>*massive* difference already.
>>>
>>>There are other statements that you made that I could discuss, but this one
>>>caught my eye...
>>>
>>>What are you talking about? What's the difference? How do you know? You seem to
>>>be implying that Chrilly did a better job than Hsu which I don't believe.
>>
>>Yes massive better.
>>
>>Hsu has written many articles.
>>
>>here is a summary of what Chrilly has said in way more words (voice)
>>when he was staying here for a few days:
>>
>>  Hsu was one of the first to make a move generator. He didn't write it in
>>  verilog but in the direct logics of the chip. Very incompatible method.
>>  Custom made by hand. It is incredible that he managed to write at such a
>>  low level anyway. However, a bad result from writing at such a low level is
>>  that the scale and size of the logics is so big that he must have
>>  lost oversight. I write in a more compatible language called Verilog and
>>  that is not comparable to C but way closer than the very 'assembly' way
>>  in which Hsu has written his logics at. It means in short that Brutus
>>  move generator therefore is very small. Note that i MUST make it small
>>  because i am commercial and more gates is more money to pay for. In the
>>  first chip i had just 50000 gates in total and that is very very little to
>>  get a chessprogram working in.
>>  From my viewpoint all the things i have seen so far is utmost beginners
>>  level. This is logical, They are hardware designers, not chessprogrammers.
>>  I focus upon the chess programming technical result. They had so much other
>>  problems to deal with from hardware viewpoint that we can not even compare
>>  it in that sense.
>>
>>Best regards,
>>Vincent
>
>I only know of a few architectures that have been used for building hardware
>move generators.
>
>1 - the Hitech style approach which is going to be very large. (Even with the
>latest and largest FPGAs I don't think that you would get 64 Hitech chips into
>one FPGA. It needs a ton of registers.)
>
>2 - the Belle style approach which returns moves in an MVV/LVA order and
>potentially based on centrality - hardly random but not SEE. Despite what
>Chrilly allegedly said, Hsu built an efficient move generator. You could fit a
>lot of those on the latest chips at 0.18 micron or below - much more efficient
>than anything going in an FPGA in terms of silicon area. It would also run quite
>fast. Hsu suffered through doing a hand layout, but the result was a really
>small move generator that would probably run insanely fast on today's
>technology.
>
>3 - some obscure architectures which had basically random move ordering. (You
>can find references in Ebeling's book.)
>
>Now from what you're saying I infer Chrilly came up with his own architecture.
>Do you have any idea what makes it novel? From what you're saying he's not
>planning on more than 2-3 plies of search in hardware so maybe he has a really
>simple move generator that has basically random move ordering?
>
>-K

ok here is facts
  a) DBII was more advanced than other tries like belle and some studentish
tries.

What you find efficient perhaps in commercial terms is still terrible
inefficient. Some people are happy for example with bitboard move generator in
software. Well at 32 bits architecture i'm 2.2 times faster generating moves
than crafty. In fact around 73 million a second after 1.e4,e5 2.d4,d5 at a
2.127Ghz K7.

That's including general code (so my move generator is not written out for white
and black, it is general code) and of course storage of moves and ordering
scores to the RAM.

That's how you must compare brutus and deep blue with each other.

both come from a different time zone.

It is like comparing a sniper rifle from 2003 with a sniper rifle from world war
1.

Distances they shot at in world war 1 and 2 with sniper rifles must have been a
few hundreds of meters.

Snipers now practice ranges of kilometers now with a single rifle.

Deep Blue was created in a time that search efficiency was not important simply
because search depths were very small. At 8 ply search depth it doesn't matter
whether you have branching factor 6 or 8.

What matters is tactics.

In hardware advantage is brute force. Optimizing the thing for efficiency was
simply not needed. Hashtables were considered new. Nullmove considered dubious
if you used it anyway.

A normal cpu's only a few had a big RAM.

I remember Schach 3.0 from around 1997. That with hashtables up to 32 megabytes
(really a lot in those days) and it had singular extensions and of course
nullmove R=2.

But despite all those toys it had a branching factor of 10.0.

Who cared? it outsearched everyone single cpu. It got 10 ply easily with a
quarter of a million nodes a second at a 133Mhz P5.

Yes that's < 600 clocks a node.

But if you can get 250k nps who cares for b.f. = 10 ?

Now where everyone suffered from speed versus knowledge problems and only some
commercial programmers started to slowly agree in one of the many discussions at
the Aegon tournament 1997 that above 10 ply search depths the piece square table
programs would get outdated as they simply didn't play better (of course
assuming updating only in the root and only using those psq) it was trivial in
those days that everyone suffered from tactical problems.

I remember how i in BLITZ could trick them. Yes in 1997. In blitz if a trick
looked to mee pretty deep, then i would gamble at it and win as they fell for
it.

Only the best commercial programs in those days, with very very little
chessknowledge inside could get through the tactical barrier just *a bit*.

Remember fastest PC processor in 1997 was the not yet sold and very experimental
PII-300Mhz.

Of course there were also alpha's 21164 at 633Mhz experimental (and overclocked
with kryo to 767Mhz at -40C at world champs Paris 1997).

So basically the programs which were not piece square table based were
struggling incredible to play tactical a bit better. I remember how with a lot
of effort i searched 8 ply in world champs 1997.

I remember how happy i was that Fritz thought for a long period of time against
DIEP at a critical moment when diep was predicting the correct move.

Only because of that fritz thought for 12 minutes, diep could reach the
INCREDIBLE DEPTH of 10 ply. So the losing move it had planned at 8 and 9 ply
failed low at 10 and it played a move that saved the game there.

Imagine my happyness reaching 10 ply back then in the ENDGAME after 12 minutes
of search.

Most programmers therefore were dubiously forward pruning. From which Rebel is
best example. See how buggy all the forward pruning is as posted at the
homepage. Brilliant for 1990 perhaps. But even in 1997 it was looking dubious.

Nullmove by Hyatt & co was considered just another dubious form of forward
pruning.

Now comes deep blue which searches 10 ply fullwidth with a bunch of extensions.
So that's called 12.2 ply then (extensions are simply added to the iteration
depth). Let's be clear it did *not* search on average 12.2 ply. Its iteration
depth was like 11 ply on average at most. More like 10.9 ply

But it extended all checks. It extended loads of captures. Forced moves.

So tactical it was equal to Schach at a 800Mhz PIII.

However, there were no 800Mhz PIIIs at that time.

So where 12 ply looks normal in 2003 as a depth which most programs get,
in 1997 it was not a normal depth for programs doing a gnuchess a look like
evaluation.

Gnuchess was considered to be using a too heavy evaluation in fact. Mobility
sucked ass because it slowed you down incredible. I remember at the time a
statement of Frans about that.

"only search depth counts, as you learn through search, not through evaluation".

So deep blue chips not using killermoves in hardware is no problem. Inefficient
search in hardware? no problem!

Only the nodes a second counts!

More nodes a seconds means more tactical strength!

Gnuchess with singular extensions and checks in qsearch and more recapture
extensions for sure will be finding the same type of tactics like deep blue and
will agree with everything with deep blue positional spoken.

But now we are in 2003.

Search no longer can be done in a rude primitive way.

Not even in hardware.

Best regards,
Vincent



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