Author: Robert Hyatt
Date: 21:43:43 04/09/02
Go up one level in this thread
On April 09, 2002 at 17:01:52, Keith Evans wrote: >On April 09, 2002 at 14:38:26, Robert Hyatt wrote: > >>On April 09, 2002 at 13:44:03, Keith Evans wrote: >> >>>On April 09, 2002 at 10:01:10, Robert Hyatt wrote: >>> >>>>On April 08, 2002 at 23:58:40, Keith Evans wrote: >>>> >>>>>So how many more of these tables are there...? >>>> >>>>That's a good question. But first, a more important question... what would >>>>be the _best_ way to do this in hardware? IE lookup tables are the best way >>>>(so far) for software... But for hardware things would probably be >>>>different. IE it would be possible to rotate the bitboards in hardware >>>>rather than storing them already rotated... This probably needs some thought >>>>as it is not always the best idea to take a software algorithm and stuff it into >>>>hardware as-is... >>> >>>I guess that it would be only be interesting if you could rotate in a single >>>cycle? >> >>Yes.. but when you think about it, for a designed ASIC, this is just a >>simply pathway operation... reading the bits from X, re-arranging them >>via simple "wires" and then delivering them to Y in a rotated form... >> >>For an ASIC, it would take some thought as to how to accomplish this, if it >>is possible... > >I'm more concerned with routing in an FPGA where the wire length is even more >dominant than in deep submicron ASICs. > >>> >>>The major problem that I have is that I don't understand what your functions are >>>really doing, so I can't really think about the big picture. I could browse the >>>Crafty source, but only after I file my taxes. (It's one of those - you owe the >>>govt $$$ years. Hard to get motivated to finish!) >> >>I can explain the rotated stuff if that is what you are asking about... > >I have your paper about rotated bitmaps and understand that concept - maybe I >should reread it though. I just really don't understand how your engine works >well enough to understand what bitmap operations could be moved into a >coprocessor and actually accelerate your program when it's running on a fast >CPU. If you could point me to the source files and function names that seem >likely then I could study that in more detail - or I can just search for the >function names that you mentioned earlier. > Make/Unmake are the procedures that update the bitboard and hash signature stuff as moves are made/unmade. Updating hash signature stuff might be a problem as the random number table is big. Trying to do a PCI bus transfer for _every_ node (make) and then again (unmake) might be a problem since the bus is not a rocket... An FPGA engine would be better as the PCI traffic could be limited by simply giving the engine a deeper search to do. This is how DB tuned the chess processor speed to the SP2 speed... >If part of your interest in this concept that it would result in smaller >datastructures for your program resulting in better cache behavior? not particularly, no. Just that make/unmake/swap/incheck represent a sizable chunk of computation cost. That's why I thought it might be interesting to discuss all the options _before_ trying to blow some FPGAs into something interesting. A factor of 2x might not be very interesting. > >This approach interesting to me because if it makes sense then perhaps it could >be applied to games like Xiangqi which would require 90-bit wide bitmaps. Of >course in Xiangqi rotated bitmaps wouldn't buy you anything, and I'm not sure >how you handle pieces like the elephant and horse which can be blocked. Let me >know if you know of an elegant solution for that. > >Regards, >Keith I don't do elephants. I do do horses, of course. :)
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.