Author: Robert Hyatt
Date: 13:31:35 08/28/01
Go up one level in this thread
On August 28, 2001 at 15:32:23, Roy Eassa wrote: >On August 28, 2001 at 13:22:46, Tom Kerrigan wrote: > >>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 > > >I used to naively believe that highly intelligent people could disagree on a >technical topic without becoming nasty. Sigh. Your one sentence has a basic assumption that might not be true in every case. :)
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.