Author: Tom Kerrigan
Date: 10:22:46 08/28/01
Go up one level in this thread
On August 28, 2001 at 09:57:30, Robert Hyatt wrote: >Suppose I have a hardware engine that is based on Crafty. I need a bitmap of >the occupied squares, but I want it rotated 90 degrees so that ranks become >files and files become ranks. I can simply pass the original bitmap thru a >set of gates that will shuffle the bits as needed and compute the rotation in >less than one hardware cycle. Pretty easy to visualize that, I hope. But now >I want to do this in software. How are you going to do this? With 64 ANDS to >isolate each source bit, 64 shifts to shift them to their pre-assigned >destination in the rotated bitmap, then 64 ORS to merge them together? While >my hardware solution took zero time? I will not reply to every part of your most recent posts. I've already spent way too much time writing these posts and can't afford much more. This seems to be the crux of the matter--your belief that CB is somehow remotely similar to DB and the similarity qualifies you to make bad guesses about DB. This is a joke. Yes, CB was written on a Cray, using special Cray/vector instructions. But these instructions are still simple, sequential, and EASILY translated to any other general purpose processor (maybe not with terrific performance, but it's still easy). CB on a PC is a "port" because it's the exact same program, just running awkwardly. In contrast, DB is NOTHING like CB. There's no stream of simple, sequential instructions at all. I don't know how you would even begin to pretend to "port" DB to a PC, especially using the chip blueprints as you descriped in your other post. For example, the DB chip has a pipeline. How do you want to implement that in software? Run a thread for each stage and needlessly duplicate huge amounts of information between the threads to simulate latching the pipeline registers? Do you want to "port" or "emulate" the cascaded adders by doing all sorts of unnecessary, intermediate addition? The idea is stupid, stupid, stupid. That anyone would think of it makes me queasy. Or that anyone would think that this is in some way similar to porting software from general-purpose CPU A to general-purpose CPU B. I don't see what your problem is with simply reimplementing DB's evaluation terms. It's not hard. They do king attack stuff? I've written code to find all the attacks to/near the kings in half an hour. I'm absolutely certain I can implement what you're doing for potentially open files in half an hour, too. I've spent a lot of time coding up eval terms from different sources (GNU Chess, HIARCS, etc.) and none of them have ever given me any real programming trouble. I'm not sure what your hangup is with DB's terms. It's convienent that Netscape cut out on you right when you were about to reply to my 5,000 nodes question. According to the estimates you're standing by, a DB node would take as long as 5,000 "normal" PC program nodes. Do you honestly believe that their evaluation is _five thousand_ times more sophisticated than, say, Crafty's? Because I sure don't. I might accept "twice as sophisticated as MChess's" or something reasonable, but what you're saying is simply absurd. So, that was the last word in this conversation, unless you feel the need to go back on your word and continue it, which you usually do. -Tom
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.