Author: Vincent Diepeveen
Date: 11:52:31 02/17/04
Go up one level in this thread
On February 17, 2004 at 13:02:01, Keith Evans wrote: >On February 17, 2004 at 11:45:33, Vincent Diepeveen wrote: > >>On February 17, 2004 at 11:39:09, Keith Evans wrote: >> >>>On February 17, 2004 at 05:52:51, Vincent Diepeveen wrote: >>> >>>>On February 17, 2004 at 00:31:56, Keith Evans wrote: >>>> >>>>>On February 16, 2004 at 11:37:54, Vincent Diepeveen wrote: >>>>> >>>>>>On February 15, 2004 at 15:14:16, Slater Wold wrote: >>>>>> >>>>>> >>>>>>> The cards, about $500 a piece. >>>>>> >>>>>>$3000 a card at least. >>>>>> >>>>>>Hydra gets sponsored by a FPGA company called Xilinx. >>>>>> >>>>> >>>>>When I recently looked at price quotes for an XC2V1000 part which is apparently >>>>>what Chrilly uses I see that you can get some speed grades for under $200 now. >>>> >>>>Chrilly needs development boards in each computer and add to that a chip with a >>>>million programmable gates. 60000 gates is really too little ;) >>> >>>Vincent - do you have any idea what a XC2V1000 is? Hint it's more advanced than >>>a XCV1000E. Xilinx refers to it as a 1M "system gate" part. (You have to use a >>>lot of the RAM for this gate count to make sense.) >>> >>>In the past Chrily said - "In Brutus I use the somewhat outdated XiLinx-Virtex-I >>>V1000E." (I think that Chrilly got the part number a little incorrect.) >>> >>>Anyways I actually used to design printed circuit boards, so you're not talking >>>to a complete idiot when it comes to PCBs. I was also the one that told you that >>>it was possible to implement killer moves in hardware when you said that it was >>>impossible. Now you backpedal and mention how it costs an extra clock or >>>something. >> >>Chrilly has worked for years to get it all to work, and the previous programs >>all didn't get it to work. So don't bullshit here that it was trivial to make. >> >>It isn't. >> >>Yes it costs extra clocks to do more move ordering because this is a sequential >>process in hardware, not a parallel process. Hardware is very inefficient >>anyway. >> >>How much for a compiler btw? > >Vincent - my definition of possible does not imply trivial. (If by impossible >you mean non-trivial then that would explain a lot.) I am impressed with the >amount of stuff that Chrilly squeezed into an XCV1000E - I am curious exactly >what simplifications if any he made in his move generator to leave room for >eval. It might explain why he only searches 3 ply in hardware. You can see how As far as i know move generator and eval are seperated. the only reason he's doing nowadays 3 ply in hardware instead of 2 ply is because he cannot stress the PCI bus too much. Of course it is just a parameter to the hardware to do 3 ply. When doing more than 2 ply the inefficiency of the search is that big that he could not avoid doing major forward pruning in hardware. Trivially Hydra is also using nullmove in hardware. Additionally the tactical strength in hardware is very poor (note Hsu also mentionned that he could not do 'dangerous' extensions in hardware). So there are no reasons to do 4+ ply in hardware other than the huge inefficiency in hardware. >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. With exception of killermoves, Hydra is using the system of using a single value to generate moves for move ordering. Depending upon the value you know which moves you already have been searching (that directly therefore gives the move ordering). >A top-of-the-line compiler aka synthesizer for Virtex parts is somewhere over >$10,000. You can get free synthesizers for the smaller parts, but it gets >expensive for the larger parts. You would probably also need the Xilinx P&R >software - aka ISE Alliance which runs $1500 at Xilinx's online store - unless >they have a bundle deal going. I guess he got it for free because Xilinx is a sponsor of Hydra. >There may be better/cheaper solutions, but in the past I found that Synplicity >gave the best results for Virtex parts. For example Xilinx has ISE Foundation >which you can get for $2500 at their online store. >Of course Universities get these products at a fraction of the price. If you go >to Synplicity's website you can see that Synplify Pro is $500 for a three year >license. >I found that the free Icarus Verilog was slow, but could be used to simulate >RTL. If you want a more capable simulator then that will cost you too. Xilinx >may have a decent deal on ModelSim - I've never used that so don't know. I do >know that Synopsys's VCS blows Icarus out of the water - but that's 10's of >thousands of dollars. I think you understand the importance of simulation when >it takes many hours or days to turn a design. Believe me, i had to wait for 3 weeks for 130 processor outputs of DIEP. I can very WELL imagine what it must be when implementing a new evaluation feature when 20 compiles take each compile a day so 20 days before something simple is working bugfree thanks to synthesizing/simulation times. Is there some free/trial simulation software of fpga? I would like to try some simple stuff in verilog (non computer chess related some mathematical software i wrote once which i want to get faster it works with big integers which are hard to simulate with just 128 bits registers), but before paying so much i would prefer some type of simulator that can give me an impression of how easy it is to program verilog. Trivially such simulator doesn't need to work fast. >-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.