Author: Robert Hyatt
Date: 21:31:17 07/28/03
Go up one level in this thread
On July 28, 2003 at 20:59:24, Vincent Diepeveen wrote: >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. In WW1 my grandfather was a sniper. He shot at ranges up to 1000 yards. In WW2 my father was a sniper. He shot at ranges up to 1000 yards. Today, a neighbor down the street is a sniper. He shoots at ranges up to 1000 yards. _nobody_ shoots a sniper rifle at ranges of "kilometers" today. "kilometer" perhaps. With an occasional attempt at up to 2km with a big 50 cal "rifle". This is just another area where you know nothing, but write as though you are an expert. BTW, Hsu's move generator is _not_ a lot better than Belle. All you have to do is read his paper to see what he did... > >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. I assume you mean 1987. We played them in 1983. In 1983 32 megabytes was _not_ really a lot to _some_ of us... > >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. I've offered you the chance to put up and prove that statement, more than once. I used a P6/200 in 1996. I'll use a P6/200 today in a blitz match against you to let you "show" your blitz skills. You hardly won a game back then. You'll hardly win a game today. Stop stretching the truth so far that you look ridiculous. > >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. That's baloney. I had a _dual_ PII/300 in 1997. > >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. Strange. I searched 11-12 plies in 1996 in Jakarta. And in 1997 in Paris. > >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. Eh? Everyone was using it in 1996. Me. Bruce (Ferret). Fritz. I don't know of many that were not, in fact. > >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.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.