Author: Tom Kerrigan
Date: 21:57:49 08/27/01
Go up one level in this thread
On August 27, 2001 at 22:52:41, Robert Hyatt wrote: >On August 27, 2001 at 19:40:42, Tom Kerrigan wrote: > >> >>Exactly. I've heard you say over and over that DB is vastly different from DT. >>And the code that's on Tim Mann's page is for DT. And it's a program for doing >>automatic tuning against GM games anyway, not the kind of tuning that was >>reportedly done for DB. Is it safe to assume that, because this is the best code >>you can produce, that you don't have _any_ actual DB-related code? And because >>you have to guess at the speed of DB code based on CB speeds, that you don't >>know _any_ specifics of the code they used? If that's the case, and it seems >>like it is, I don't see what business you have making the guesses you've been >>making and passing them off as informed estimates. > >Nope. The DB guys have reported that they used the same approach. Obviously Then why was I reading so many stories in Newsweek and whatnot about how some GM was playing DB constantly and the programmers were changing the function to avoid moves that he didn't like? How could they be doing this and simultaneously relying on the automatic tuner? Why have the GM there at all? And what was the GM playing before the chips were fabbed, if not a software version of the algorithms? Doesn't make any sense. >Today's cpus _are_ "that far away" from sustained 10 BIPS. Which is what he >said might be enough. "might be". Because in some respects he is just like Nope. The paper doesn't say "might." And today's processors can sustain more than one instruction per cycle, meaning that cheap, readily available computers are pushing 2k MIPS. If Hsu is to be believed, that means a fast PC would be twice as fast as the single DB chip that took apart all those micro programs. Surely that's strong enough to be interesting? >me... He hasn't given a lot of thought to how he would do something in a >software program that he is currently doing in hardware. My vectorized attack Oh, I see. You treat every single word that dribbles out of his mouth as gospel, unless he says something you don't care for. Then he just "hasn't given a lot of thought" to it. >>(BTW, if you're interested, the same paper says that the DB chip took three >>years to create. This is a far cry from the 9 months that you stated in another >>post.) > >You are reading the wrong stuff. The _first_ DB chip took maybe 3 years, >and if you had read everything he wrote, and attended a lecture or two, you >would know why. There were some interesting problems he had to overcome that >had nothing to do with chess. Pads on the chip were too large. Cross-coupling >between signal lines on the chips that was unexpected and required some cute >hardware work-arounds. Complete batches of chips that were botched for various >reasons. I don't see what this has to do with anything. I said it takes months or years to make a chip. You say no, it took months. Now you say a different chip took years. Either way, I'm right. You're sitting there working yourself into a lather, trying (and failing) to contradict something that's only tangential to my point. >>Okay, so what is it? Is it one with a pawn lever? Or one without a pawn ram? >>Seems like both of those could be considered potentially open files, and they >>aren't exactly expensive to evaluate. > >Says the man that hasn't evaluated them yet. :) > >You have to see if the pawn can advance to the point it can make contact >with an enemy pawn without getting lost. It is definitely non-trivial. >From the man that _does_ evaluate them now. Bully for you. You have your idea of what a potentially open file is, and I have other perfectly legitimate ideas. And you obviously don't have a clue what DB's idea is, or you would have told us by now. And that means you don't have a clue how expensive their term is. And that means I'm still not impressed. >Only those that haven't done this. DB was written in C. Plus microcode for >the chess processors (first version). Plus evaluation tables. The issues are >the same. Porting a program from one environment (hardware or vector in my If you want to think that porting your stupid population count function is in any way even similar to porting DB's matricies of evaluation cells, fine. You're flattering yourself. >>Again, assuming your 1M figure is anywhere near accurate. You're claiming that a >>DB node is worth about five thousand (5,000) (!!) "regular" PC program nodes. >>What on EARTH can POSSIBLY take 5,000 nodes worth of computation to figure out? >>You're going to have to do way better than your lame "potentially open file" >>thing to sell that to anyone. > >I'm not saying any such thing. I simply said that they do a _bunch_ of things Of course you're saying any such thing. You're saying DB would take a 1Mx perf hit. It searches 200M NPS. Do the division, you get 200 NPS. PC programs search 1M NPS. Do more division. You get 5,000 PC program nodes searched per your hypothetical DB node. Let's try this again, what on EARTH can POSSIBLY take 5,000 nodes worth of computation to figure out? >That's all I have said, although I _have_ said it often. You are trying to >mix up the emulation of their evaluation, which I say would be hugely slow >on today's PCs. So, to be clear, the Hardware they had was quite good. And >sort of software emulation would be highly ugly. Because things done in I didn't bring up the idea of "emulation." I've been talking about re-implementation of the algorithms. You don't have to emulate anything to do that. You seem to think that software DB has to recognize a bishop pair by having cells and pipeline stages and cascaded adders. Why not just count the stupid bishops? Why is the idea of simply writing terms consistently escaping you? Why do you keep talking about "emulation" and "porting"? Does the idea of DB's eval running reasonably fast in software upset you so much that you're in denial? I'm going home. -Tom
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.