Author: Pete Galati
Date: 14:07:01 11/09/99
Go up one level in this thread
On November 09, 1999 at 15:30:46, Dann Corbit wrote: >On November 09, 1999 at 14:55:40, Pete Galati wrote: >>This week the local pbs station ran a Scientific American program about robots, >>most of it was about robots that tried to emulate movement of cockroaches and >>tuna (not so easy). >> >>But the more interesting part of the program was focussing on teams of small >>independent robots who works together to play socker and there was separate >>developement teams who competed agaist each other with their teems of robots, >>this was fun to watch this part. >> >>I forget who won the tounament, it might have been Cornel Univ. >> >>So the next day I more or less associated this with what Dann was talking about >>with using a large amount of CPUs to run a program since each cpu could be >>dedicated to a peice. My memory's a bit foggy about what Dann had said about >>how he planned to do this though. >> >>In my mind the way I would see it being done would be 1 cpu for the 8 pawns, 1 >>cpu for the 2 Knights, 1 for the 2 Bishops, 1 for the 2 Rooks, 1 for the Queen, >>1 for the King, and then 2 more cpu, 1 for the commanding general (not a piece, >>and 1 last cpu for the medics (not a piece) and the medics job would not really >>be to care for the dead piece (captured) but to account for and repair the >>damage done. 8 CPUs >> >>Too far fetched? Probably. I don't remember how Dann related what he was >>attempting, and I probably won't dig his posts up. I just wanted to throw the >>concept out there the way I see it. Is that more or less what you're doing >>Dann? >My idea is more related to permutations than to pieces. If I have some board >position p, there are a set of possible subsequent positions one ply later. So >I do this: >0. Have a thread that analyzes the root for ce. This thread is permanent for >the duration of the iteration. >1. Have a thread that analyzes the root for checkmates. This thread is >permanent for the duration of the iteration. >2. Have a thread that analyzes each possible next position. These threads are >transient. After a time period called heartbeat, they check back in. The ones >that are not finding anything good abandon their tasks and analyze subsequent >positions from the ones that are doing well. > >This method obviously takes a pile of CPU's and the more the merrier. It will >work effectively only at the longer time controls but will work well on message >passing machines and other non SMP architectures. Sounds like it makes more sense, I'm assuming that you'd have a separate proccessor organizing organizing the 3 threads mentioned. When you say "message passing machines and other non SMP architectures" this is terms unclear to me, but how I interpret that is that you'd have completely separate computers networked together. There was an atricle in Linux Journal many months ago about somebody who had a large amount of PC tower computers somehow networked together to use as a substitute for a mainframe monster, it was said to be more economical, but it looked like a nightmare to me. I don't remember any details, it was all over my head. Pete
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.