Author: Robert Hyatt
Date: 21:19:54 04/06/00
Go up one level in this thread
On April 06, 2000 at 22:59:11, Tom Kerrigan wrote: >On April 06, 2000 at 18:13:54, Robert Hyatt wrote: > >>Unless you design a hardware processor, of course. Then _anything_ is within >>reach if you want it.. :) > >Sort of. > >I've been reading about these hardware processors, and they are definitely not >trivial. They are complicated even if you don't account for weird moves like en >passant and castling. > >Right now, it looks like Hsu's move generator logic would not even fit on the >FPGAs that I have access to at CU. > >It would be possible to do a hardware-ish SEE using a Hsu-like chip, but there >are complications. > >First of all, you would have to keep track of a list of moves. Not only does >that add relative complexity, but you also have to make the list, which negates >one of the big advantages of the hardware move generator, namely that you can >generate the moves in order. > I would parallelize the Hsu/Thompson design. Do a find-victim/find-aggressor cycle for black and white in parallel. This is a one-cycle operation... with slop left over... so it would probably be slid in between some other necessary things to hide the cost totally... Typical SEE cycle would take two to three such cycles since most cases (at least last time I counted them) had only one or two attackers for one side at most. It would not be easy... but it would definitely be doable. I wouldn't want to try an FPGA design, probably, but an ASIC? Hsu was looking for things to take up the last bit of real estate on his ASICS. a SEE 'block' would be a useful addition (IMHO) >Second, you would use the move generator to enumerate the SEE captures. In terms >of performance, think of it like this: how fast would Crafty be if you had to >run your move generator several times for each call to SEE()? I would use part of the move generator (find victim/find aggressor code which scans the chess board squares in parallel)... Hsu's 'move generator' was a tiny part of the overall chip... just as my move generator is a tiny part of the total source code... But for SEE I would not use the same hardware, I would modify it as discussed above to rip thru white and black attackers in parallel. > >If you have access to a really badass process, like 180nm or something, you >might be able to put several move generators on one chip and generate the >appropriate moves in parallel. But I think this would be an extraordinary waste >of silicon. Remember how small Hsu's generator was. On that single chip, most of the area was eval. + move generator. + search. + qsearch. + a KPK endgame database and associated probe circuitry. etc... > >So I shudder when you say "anything is within reach of hardware." It might be >within reach, but it might not make any sense to do, or it might be a phenominal >pain in the butt to do. > >-Tom no doubt it would be a big 'pain'... But then, so was parallel search. But the gain... :)
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.