Re: [computer-go] Hardware-Instruction.

[Vincent Diepeveen <diep@xxxxxxxxx>]

At 08:59 5-11-2004 +0100, chrilly wrote:
>>
>>Someone (can't remember who) makes simulators that use an array of FPGAs to
>>simulate your ASIC design.  Way faster than software, but still slow.
>>
>At the beginning of the project I visited MIT (unfortunately Don Dailey was
>out) and they had such a simulator. >100 FPGAs. Besides the Powerball-detail
>Hydra is a combined hardware-software system. There is no straightforeward
>way to combine/interface these 2 systems.
>A more realistic way would be to develop first an FPGA and to convert then
>to ASIC. The problem with this approach is, that the ASIC design reflects
>then also the limitations of the FPGA-architecture. Competitive ASICs
>structures - e.g. 130 nanometer - masks are also too expensive for a game
>playing program. I think the more realistic way is to wait till reasonable
>sized FPGAs are below 50$.

$50 a chip if you print 5000 or so, + $100 a card = $150 production price,
not counting the shipment and things like support cdrom and the $50 that
chessbase needs additional for their interface a product.

Product box goes to importer. Man takes a lot of risk as odds are big he
doesn't sell even half of his cards, so he needs to earn factor 2 
wants $600 a card.

card gets to shops and gets sold for $800-$1000 a piece there.

>> Can you describe your >architecture?
>>
>See enclosed paper.

This story looks very old and i assume you compared only to deep blue. Of
course anything you compare of hydra to deep blue, hydra will be better.

No one doubts that.

All comparisions to software are of course in your disadvantage.

  a) your development is of course very slow compared to software and
testing is also 100x more difficult. Basically without fulltime team
working for you, you can not do the same like single persons manage in
software.

  b) your parallel speedup is a major bullshit of course. You compare
probably a very inefficient single cpu setup versus 8 cpu's there and i
fail to see all significance. Why not do an automatic test such as i did
with diep here with statistical signficiances added at 213 positions
instead of 1 or 2.

  c) your hardware implementation is of course a good example why things
can get done fast in hardware in theory. However you fail to mention that
search is a sequential process and that you will lose many cycles there too. 

Note that by now Diep is 3d of the world and also has won dutch
championships. Diep is heavily knowledge based.

  d)
Most important is the average reader will not understand why software is so
efficient versus hardware. It is true that in hardware you can do a node in
a cycle or 10 and that in software it eats tens of thousands of cycles.

However adding knowledge in software is for free too, just like in hardware.
Because with general 'if then else' which eat at most like 25 cycles in
software, you can very quickly filter away more or less logaritmically
patterns that do not apply.

If for example for 100 patterns it is necessary to have a piece on b1 and
there is currently nothing on b1, then you just need 1 compare, not 100.

So very huge evaluation functions in software do not get much slower when
adding knowledge when suffering the first tens of thousands of cycles.

Then what keeps left is the quality of the implemented knowledge.

Knowing in hardware making complex logics, showing that you claim you can
do things in just 3 cycles (when implemented in hardware, diep's evaluation
would be a lot more than 3 cycles), already proves that you simply didn't
implement much knowledge in hardware. 

Especially the fact that majority of my time to the engine diep goes to
implementing knowledge, would mean that you never get ready in your life
implementing the same like i have currently in DIEP.

In GO programs this is even a bigger problem. The bigger board allows more
patterns. So a hardware solution there will show this evaluation
implementation problem even more as it is more difficult to write things in
hardware than in software. Not to mention that within 10 seconds i can
check whether i implemented a pattern correctly in diep and you cannot in
FPGA do that at all.

How do you debug patterns in fpga?

In software it is easy, i can verbose show my evaluation function.

You need weeks of debugging your hardware for just 1 pattern.

  e) i see a difference between what Ulf Lorenz told me about Hydra versus
what you optimistically write in this document. 

>Chrilly
>
>
>
>Attachment Converted: "f:\internet\eudora\attach\hydra1.pdf"
>_______________________________________________
>computer-go mailing list
>computer-go@xxxxxxxxxxxxxxxxx
>http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/