Author: Bob Durrett
Date: 07:48:17 02/18/04
Go up one level in this thread
On February 18, 2004 at 04:42:13, Vincent Diepeveen wrote: >On February 17, 2004 at 15:43:51, Keith Evans wrote: > >>On February 17, 2004 at 14:52:31, Vincent Diepeveen wrote: >> >>>On February 17, 2004 at 13:02:01, Keith Evans wrote: >>> >> >>>>many gates Marc Boule's move generator takes in a Virtex, and my own attempt >>>>wasn't much better. But anyways I have actually implemented a hardware based >>>>move generator, and ran some perft tests on it, so I do understand Belle style >>>>move generation and its limitations. However I don't know if Chrilly did a Belle >>>>style generator or not. I didn't go further with bolting search and eval onto >>>>the Belle style move generator because I didn't want to have to make a huge $$$ >>>>investment to get something competitive. >>> >>>Chrilly quantified these move generators as complete beginners stuff. >> >>Well of course since they published all the details to implement them, then > >In fact the deep blue generator see IEEE 1999, several pages about just the move >generator. > >>anybody can do so. (You can even download Marc Boule's VHDL code for kicks.) >>Chrilly did hang out with Ken Thompson for a while to pick his brain. I'll bet >>that Chrilly's generator is actually simpler than a Belle-style generator - not >>that this makes it inferior. Or he may just have figured out a better way to >>exploit the resources in the Virtex parts and it's equally complex. (For example >>maybe he is using the on-chip "tristate" busses for arbitartion rather than a >>big tree. Or he doesn't handle promotions? Castling? ...) > >He has to handle this in hardware as he's doing a 3 ply search. missing castling >or promotions there would be a severe handicap. Let's check my email for answers >from Chrilly. > >>Since I don't know what he did, then the mystery makes me interested. If I did >>know, then I would probably be disappointed. Given that he only runs at 30 MHz I >>can infer something about his longest combinatorial path... (We have a pretty >>complicated DSP implemented in a Virtex-II and get it to run at 80 MHz without >>really doing anything special to target an FPGA.) > >But they had already 10 cards from 30Mhz a few years ago. > >I do agree however that FPGA isn't keeping up with GP speeds. > >>But obviously Chrilly did not figure out some great mystery, otherwise he >>wouldn't need to throw so much hardware at the problem. With so many powerful > >Hydra is using attacks in evaluation, its play clearly shows that. This is not >so easy to do real quick in software. Remember DIEP gets 100k nps a second on a >fast K7 or P4 and just 150k nps on a 2.2Ghz opteron (in 32 bits). > >I doubt however Chrilly uses a lot of pattern knowledge. Would take too long to >develop in hardware. This is interesting. Some things that work well in software for the PC may work poorly in a given type of hardware and visa versa. I was intrigued by the possibility of making a hardware implementation of Crafty software, but perhaps much of the code in Crafty may have to be scrapped and replaced with other code more easy to convert to hardware. I can see also the possibility that there would be many design tradeoffs which would come out differently in a hardware implementation versus a software implementation [on a PC or other general-purpose computer]. Converting an existing software engine to a hardware engine would likely be sub-optimal for the above reasons. On the other hand, it might still be a worthwhile endeavor since the exercise would point to better ways to make the hardware chess engine in the future. When working with hardware, its always necessary to work within the existing state-of-the art and using existing hardware. This is a compromise which software people may not have to face other than having to use existing compilers. Just thinking out loud. : ) Bob D. Bob D. > >It's for sure however that some things he does which i have too in DIEP, that >they *do* eat significant amount of system time, which are for free in hardware. > >This in contradiction to deep blue. From its play you can easily see that it has >some simple mobility function type gnuchess and plays like gnuchess and nothing >more. In fact the proof is trivial there. ZarkovX is the only program on the >planet that wants to play nearly all moves that deep blue also played in the >match. It's like a 95% match where all other programs have like a 70% overlap at >most (playing a lot of better moves). No attacktables nor any difficult scan in >eval at all. > >So the software version from hydra is doing scans which drops the nps bigtime. > >Any Fritz a look like speeds are hard to get. > >This is its big speed win. > >No you can't compare this to crafty. Crafty is doing something so simple and >primitive, it's near the leafs doing way less than any of these programs is. >Even deep blue did do a few checks in qsearch. > >>CPUs in the mix you could just leave the FPGAs idle and still have a competitive >>program. > >I simply do not know the efficiency software versus hardware and chrilly like >the deep blue team will shut up about this forever i bet, or tell unrealistic >stories. Chrilly shares with the deep blue team in that respect the same >mentality. > >Yet when we just look to the nps count, then it's trivial that Hydra gets a >factor 10 more nps in hardware than it would do in software. > >>-K
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.