Author: Keith Evans
Date: 15:57:20 06/29/02
Go up one level in this thread
On June 29, 2002 at 17:48:26, Uri Blass wrote: >On June 29, 2002 at 17:04:01, Keith Evans wrote: > ><snipped> >>I don't understand your question about knowing what Hsu did? His move generator >>is pretty well documented. > >I know nothing about that and I think that there are a lot of people who know >nothing about it. OK. If you want to know, then you might read: "Large Scale Parallelization of Alpha-Beta Search: An Algorithmic and Architectual Study with Computer Chess" CMU-CS-90-108 This one is Hsu's thesis and describes Deep Thought. It also presents his idea for how to do repetition detection in hardware, which he didn't do until Deep Blue II. I don't know if the ideas for parallel alpha-beta are superceeded by newer methods - not my strongpoint. Next up: "IBM's Deep Blue Chess Grandmaster Chips" 0272-1732/99/$10.00 IEEE This one describes Deep Blue - the move generator is described fairly well here. The evaluation is not well described. Finally: "Deep Blue" Artificial Intelligence 123(2002) 57-83 You'll get a better idea about the capabilities of his evaluation function here. If you're just into software solutions then this might be the most interesting one, just for the list of eval features so you can compare it to what you do in your program. > Unfortunately the thought processes behind the >>decision to add additional capabilities (checking, check evasion,...) when going >>from Deep Thought to Deep Blue are not well documented. (I'm talking strictly >>about the movegen not about eval here.) >> >>That's why I'm so interested to see the responses. I barely have an opinion on >>the matter, other than that I am interested in building a minimalistic move >>generator in hardware, and obviously don't like unnecessary complexity. >> >>Regards, >>Keith > >How much speed improvement do you expect to get relative to the commercial >programs? No idea - maybe none. It might make more sense for handheld devices given the speed of high-end CPU's. Actually my intuition is that the move generator is probably the wrong place to start for a high-end system - an evaluation coprocessor would probably make more sense. The evaluation is a more difficult problem - although my guess is that it would probably be easier to integrate and debug an evaluation coprocessor than a Deep Blue style chip. After doing that then one could consider doing a movegen and integrating the two with search ala Deep Blue. The move generator is a fascinating thing nevertheless. There's a basic limitation with the Belle style generator in that it can't be pipelined, and that alone makes it interesting to think about alternative architectures. Also some of the concepts that one would use to build hardware eval are present in a Belle style move generator. >I doubt if building a special hardware for chess is a good idea. There's really no rational reason whatsoever that anybody should be working on chess engines, right ;-) I'm a hardware engineer so I naturally choose to approach the problem from a hardware angle. Isn't it intriging that a pure hardware move generator can be built in a relatively common FPGA and perform at a similar level as a high-end full-custom CPU? And do it while being clocked at a measly 30 MHz versus the 1 GHz+ that the CPU requires? The reason that someone might want to approach this from a hardware point of view is that FPGA technology is making huge strides. Xilinx is even making or going to make an FPGA with four embedded PowerPC processors. They're only something like 300 MHz processors, but they are surrounded with customizable logic, and have high-speed interconnect for off-chip communication. If there were money to be made building high-end chess hardware, then you would see some amazing developments. You could make a very strong argument that before one spends any time coming up with a hardware solution, that one should write chess playing software to understand the problems. >The advantage of concentrating in software is that the same program can be >faster when the hardware becomes better when things like deep blue are going to >be always at the same speed. > >Uri Technical arguments aside, the reason that Deep Blue will always be at the same speed is that IBM has no interest in making it any faster. Some advantages of working with software are that you can get pretty far with a sub $100 used PC and a free copy of Linux, then when you're ready buy a high end SMP system for under $1500. When you are going to a serious competition you could even beg, borrow, rent, steal time on a supercomputer and get super high-end performance without making much monetary investment. Whereas for hardware design you'll spend thousands to tens of thousands on yearly maintenance fees for your tools alone. It's also much easier to find testers for pure software engines, and it might give you great pleasure to have users all over the world using your program. So I'm not a hardware fanatic. But custom hardware sometimes makes a lot of sense. At work we recently made a chip which fits in a tiny 8 mm x 8 mm package (actually it could even be smaller) and does work equivalent to a board full of DSPs at a fraction of the cost, a fraction of the space, and while consuming far less power. It basically just does correlation - can't do anything else. But it does it very well. Regards, Keith
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.