Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Multi-Hydra Computer Feasible in Future?

Author: Bob Durrett

Date: 19:09:41 02/17/04

Go up one level in this thread


On February 17, 2004 at 20:51:04, Robert Hyatt wrote:

>On February 17, 2004 at 14:52:31, Vincent Diepeveen wrote:
>
>>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.
>
>I don't see how to reconcile the above statement with...
>
>
>>
>>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).
>>
>
>
>
>that statement.  That is _exactly_ how belle and dt/db generated moves.  So what
>is so "beginners stuff" about it if he duplicated it.  I also find it
>interesting that it took him 10 cycles to process a node, the same as in belle
>and deep thought/deep blue.  So maybe they didn't do so much "beginner's stuff"
>after all, particularly knowing that Ken Thompson was advising him during the
>design phase...

Sometimes it's tough to come up with an idea or a design the first time.  Vis:
the wheel.  After that, duplicating it can be "kid stuff."

Bob D.


>
>
>
>
>>>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 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.