Author: Uri Blass
Date: 14:01:35 12/12/05
Go up one level in this thread
On December 12, 2005 at 14:38:48, Chrilly Donninger wrote: >On December 12, 2005 at 13:48:30, Zappa wrote: > >>On December 12, 2005 at 13:15:05, Joshua Shriver wrote: >> >>>Imagine Rybka on Hydra hardware and interface card to the FPGA boards :) >>> >>>-Josh >>> >>>On December 12, 2005 at 12:56:41, Ziad Haddad wrote: >>> >>>>Is this match possible in the future? Could hydra hold on? Did a multiple CPU >>>>version of Rybka will be available? Hydra must fear this. >> >>I can't stand comments like this. >> >>In order to port an engine to hardware, you basically have to rewrite it from >>scratch (admittedly using the same ideas, but still). It'd only be 2 years of >>work or so . . . >> >>anthony > >Well, the main problem is, that you can not even use the same ideas. Its a >different world and one has to find own solutions. Forgetting about Nimzo was >the hardest part in the Brutus/Hydra project. This is in both directions. Some >things which one avoids in software, because they are very inefficient, are in >hardware cheap. What do you mean very inefficient? How much speed reduction do you expect to get from implementing them in software. One has to overcome the old reluctance to implement these. E.g. >In Nimzo I had only a fast approximation for mobility terms. Accurate mobility >is almost free on the hardware. What do you mean by accurate mobility. Do you consider mobility evaluation of Fruit as accurate mobility(every piece get a score based on number of moves that it has) and if not then I am interested to know if somebody can explain in english what is accurate mobility. Some constructs are in contrast on the FPGA >almost impossible. E.g. the size of RAM-Tables is fixed to 4 (old Virtex-I) and >now 18-KBits (Bits not Bytes). One has to split up everything that it fits into >these small tables. And one has also to restrict the possible values. A typical >Hydra-Tables as 12 Bits Input and 4 Bits output or just 16 different values. >One has also to avoid any sequential thinking. E.g. I calculate first the pawn >structure and the rest of the eval depends on this. In Hardware this runs all >parallel. If one makes it sequential, one has already lost. I guess that you mean that you lose speed but the question is if speed is everything and if it is not possible that it is better to have more correct evaluation by sequential thinking and be slower. Uri
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.