Author: Robert Hyatt
Date: 06:40:26 01/25/00
Go up one level in this thread
On January 25, 2000 at 06:20:22, Amir Ban wrote: > >Yes, this makes a good point. > >I can't directly answer "what can't they do ?" without studying in depth the >chip design, and probably needing more information than was ever published, but >I know on general grounds that to say that the chip could do anything and in >zero cost is just hype. Not really hype. see my previous post. why else include a kpk endgame database on the chip? When I first saw this I asked the same question. The answer was "we had unused chip area and this was the best thing we could think of quickly since we already had an eval that was over 75% unused (at the point of the design of DB2... this later dropped to 50% unused as they added more terms using the new hardware). > >The hardware/software tradeoff doesn't work this way. Hardware is not only more >expensive, but also less flexible. In software you can do anything. In hardware >you have to adopt some model in which you will try to fit the features. If your >feature fits the model, great, and then the cost will be about zero. If it >doesn't fit the model, forget it. > >Even from the brief description available for the chip I can see the model in >broad outline. The main part of it is piece-square tables, which are in RAM, and >most probably downloaded from the host when the chip gets a position. This is a >sensible and flexible way to do this, but it means the chip doesn't do true node >evaluation, but is a hybrid preprocessor (like Junior). > It isn't a piece/square program. It has large tables of eval terms, but just like those done in crafty, which also is not a piece/square program. These arrays are indexed to obtain scores, and the index can be anything, from material remaining, to a bitmap of (say) 8 features that in combination are used to index a score (again as I do). They were _never_ a piece/square program, as that doesn't take any hardware at all to do that. They were much more.. >There is a second part of the evaluation that falls under the heading of "slow". >If I remember right, it takes three cycles, and relies on a pipelined row or >column scan. They have an impressive array of features they say is done this >way, but it's clear this relies on modeling the feature to fit the particular >method of pipelined scanning. A feature that won't fit into this mold won't fit >anywhere. > You are thinking too rigidly. You don't first build the mold, then find the features that fit it. You first find the features you want, then design the mold to fit those. That was the entire purpose of DB-2. >Another really obvious point is that even a feature that fits perfectly into the >model, but is not currently implemented would need a 6-month cycle to implement, >more if first silicon fails. This is not so practical if you have a year between >matches that you want to devote to working with grandmasters to improve your >evaluation. I'm sure that they did their best to avoid this dilemma, by making >the chip as parameterized and customizable as possible, but by doing that they >forced upon themselves a constrained model, and only bought themselves a small >percent of the flexibility and programmability that a software developer has for >free. flexibility is a problem if you overlook something in the design. But if you design the hardware to compute things that you don't see how to use right now (ie which pawns can advance how far without hitting another pawn, or without reaching a square where more pawns attack that square than defend it, as one example... right now you might not have a clear idea of how to use that, but who cares? If it seems reasonable, and chip area is available (and in DB plenty of chip area was available in the second version (not the first)) then you do this and later figure out exactly how you want to use this. According to Hsu, they were using less than 50% of the things they evaluate at the time of the second match... they didn't have time to use the rest... > >Finally, since it's Bob asking the question, I suspect he's only aware of what >crafty can do, and regards everything else as not practical in software. I see >this, for example, when I say up in this thread that I can do something for >free, and Bob "refutes" this by telling that he's done it in crafty and it's not >free. It's in line with his theory that we all started by downloading the crafty >sources and built on top of that, but this is not true of course. > >Amir I don't recall using 'crafty' to "refute" anything you said. If you'll point out the post, I will certainly correct that is it wasn't something I would intentionally say or imply... we have vastly different programs. which suits me just fine. Just as our programs are _vastly_ different from what was done in deep blue...
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.