Author: Robert Hyatt
Date: 16:55:33 12/20/99
Go up one level in this thread
On December 20, 1999 at 16:23:24, Greg Lindahl wrote: >On December 17, 1999 at 21:12:52, Robert Hyatt wrote: > >>It certainly is. I specifically said "you are going about it wrong". And "it" >>is not the FPGA approach... it is about your not wanting to understand the >>serious problems ahead, _first_. > >So I can't ask who's interested in the problem first? OK, if you say so; I'm >proud to do it all wrong if that's the case. BTW, I am very interested in the >problems, and I've been learning all about them from some other people, and they >have been nice enough to not tell me I am "going about it wrong". > >>>Incorrect. If the FPGA design doesn't need any memory, then no one needs to >>>solve the problem of getting memory in an FPGA. You pointed out a straw man. >> >>No, _you_ are incorrect. The chess engine _must_ have memory. > >FPGA boards come with separate SRAM chips. I said: getting memory in an FPGA. > >> So a pure FPGA design isn't going to work. > >Even though today's typical FPGA card has SRAM available? Their main market is >FFTs. As you know, an FFT requires memory, and the board manufacturers >distribute a library implementation that uses the SRAM. > >>You originally said you >>wanted to do the eval in an FPGA design. That is no good. At the very best, >>you can speed up a chess engine by a factor of 2-3, assuming that they use 2/3 >>of the compute cycles in the eval. > >This is not true for all chess engines. There are engines other than yours that >have a higher % of time in the eval. It's an interesting trade-off. Remember that there are at _least_ as many that spend less time in the eval than I do. And that I doubt if anybody is as high as 90%. > >> DB proved that to >>make the thing fly, the _entire_ engine. > >DB proved that you can make a fast engine by putting it all in a chip. > >DB did not prove that other approaches could not build a fast engine. DB didn't, but belle did, and hitech did, and so forth. Whatever you put in the hardware goes fast, but everything else stays the same. Chess engines are pretty well-balanced between eval, search, make/unmaking moves, hashing, evaluating sequences of exchanges, doing move ordering, etc. There is no one piece you can pick out and make execute in zero time, and produce any big performance boost. DB/1980 Belle were the only examples of a full hardware implementation of the search (there was BeBe also, almost forgot). They were the primo examples of fast, also... > >The DB approach maximized the design cycle length and costs. No, no, _NO_... They spent 12 years maximizing _performance_. Not anything else. They built on 10 years of Belle doing the same. It was all about performance. No, they didn't use the most expensive production process. But the internal design was _very_ complex and no decisions were made based on making it simple. It was all about making it _right_. > >There might be more than one way to skin a cat. Possibly... but after several _very_ bright people, and 20+ years, we are still stuck with alpha/beta and all the trimmings. Doing "less" than DB/Belle did doesn't seem to be the path to the future... > >>Good luck, as I'd love to see something hardware-ish. > >Thanks for your kind words. > >-- g
This page took 0.01 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.