Author: Tom Kerrigan
Date: 21:20:55 08/27/01
Go up one level in this thread
On August 27, 2001 at 16:19:17, Robert Hyatt wrote: >On August 27, 2001 at 14:53:10, Tom Kerrigan wrote: > >>On August 27, 2001 at 14:21:41, Robert Hyatt wrote: >> >>>On August 27, 2001 at 13:47:27, Tom Kerrigan wrote: >>> >>>>On August 27, 2001 at 13:35:13, Robert Hyatt wrote: >>>> >>>>>On August 27, 2001 at 08:59:00, Robert Hyatt wrote: >>>>> >>>>>>On August 27, 2001 at 04:14:33, Tom Kerrigan wrote: >>>>>> >>>>>>>There are some issues here that have not received due attention. >>>>>>> >>>>>>>First, [as most of you already know,] part of DB's search algorithms and all of >>>>>>>DB's evaluation function algorithms were implemented in custom VLSI chips. This >>>>>>>made it phenominally fast and also means that it can't exist as a PC program >>>>>>>(because you don't have the chips). However, PCs have general purpose >>>>>>>processors, which means they can run any algorithm you can think of, so the idea >>>>>>>of running DB on a PC isn't quite as stupid as most people seem to think, if >>>>>>>you're talking about the algorithms. There are two issues at play when >>>>>>>discussing implementing DB as PC software: >>>>>>> >>>>>>>1) Work involved. Speaking from experience, the time-consuming part of writing >>>>>>>an evaluation function is not the actual coding, but instead deciding which >>>>>>>terms to include and what their weights should be. If you already know _exactly_ >>>>>>>what an evaluation function is supposed to do, (and the DB team does,) I bet >>>>>>>implementing even the most complicated one would only take a couple of weeks. >>>>> >>>>>I missed that statement first time around, until someone sent me email. I >>>>>don't know what kind of evaluation _you_ have written. But _mine_ was not a >>>>>two week implementation project. None of mine have been two week projects. >>>> >>>>Sounds like you're accounting for development time. Are you saying that, given a >>>>list of Crafty's evaluation terms and their weights, you could not reproduce the >>>>function in two weeks? I bet I could. >>> >>>I would have no chance, no. Just the code to recognize blocked pawns, levers, >> >>Differing opinions. You (or at least I) can write a _lot_ of code in 80 hours if >>I already know _exactly_ what it's supposed to do. (Notice that I'm not talking >>about perfectly optimized code, which wouldn't be necessary. No amount of >>stupidity could get an evaluation function down to 200 NPS on today's PCs, which >>is what you get with your made-up 1Mx slower figure.) > >Just because I know exactly _what_ a piece of code should do does not mean I >know exactly _how_ it should do that. Probably nobody does the pawn lever Like I said, perfectly optimized code is not necessary. If I wanted to evaluate doubled pawns, I could do it super fast with some sort of bitboard or pawn population array or something. But I could also march up and down the file and count other pawns on it. It wouldn't kill me. TSCP does this and it's plenty fast. And it doesn't take a lot of thought to look at the other squares of a file to see if there are other pawns on a file. >He fabbed it a project MOSIS. I believe that was somewhere on the west coast, >funded by NSF, to provide a reasonably state-of-the-art fab facility for those Okay, I found some info about this on the web. The MOSIS process was 3 micron, which wasn't anywhere near state of the art, considering the 386 was released in '85 with a 1.5 um process. Basically, I don't care if the original Deep Thought chips cost a couple grand. That doesn't mean the DB chips only cost a couple grand. That kind of slack reasoning will get you nowhere. >>So he freely admits that he spent significant effort and money (not even his own >>money, either) implementing algorithms that he didn't even pretend to test or >>even experiment with? Unless you're just making this up, my opinion of the >>project is now way lower. >> >I'm making it up. I do it all the time. Never any factual information in >the things I write, just wild speculation and nonsense. Of course, you _could_ >just email him and ask about all this nonsense I mention. And of course, major >chip manufacturers have _never_ sold chips with unused circuits on them. Unless >you count Zilog and the old Z80, and then Intel. And Motorola. Most vendors >have shipped chips with non-described opcodes that worked on some chips, but >not on all. Because they didn't have time to test them, or later decided that >they were not needed. Or they would delay the announcement of them to the next >generation to make the gap larger. Etc. I never said the DB chips didn't have unused eval terms. Implementing eval terms because you think they might be useful is one thing; the way you tell it, DB magically had so many terms that nobody knew what to do with them. >I don't see (a) why this sounds bad (b) why this would lower your opinion >(c) or why you would even make such a statement. My opinion just went down This sounds bad because once something is comitted to silicon, that's it. If Hsu designed a ton of logic to calculate mobility one way, only to find out that it would have been much better to calculate mobility a slightly different way, then he's screwed. The simple preventitive measure is to play with the terms in software until you're satisfied with them. If this doesn't sound like a good idea to you, well, I hope to God you never end up in charge of anything important. >I have no trouble walking around with my head up, even though I know their >"thing" was better than my "thing". (to use bruce's term). I can live in that >world. You have to also... You've got to be KIDDING me. Do you honestly think I'm posting because I think my stupid micro program is better than DB?? And how do you figure that I'm finding fault with DB?? All I'm doing is finding fault with _your_ idiot estimates and assertions. Just because I think DB is _potentially_ not as good as you seem to think doesn't mean I'm finding fault with them. The idea is absurd. -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.