Author: Pete Galati
Date: 09:27:57 11/10/99
Go up one level in this thread
On November 10, 1999 at 04:20:21, Bas Hamstra wrote: >It looks like threads will be continually created and destroyed. Doesn't that >give a lot of overhead? > >Regards, >Bas Hamstra. Are you complaining about something? I don't follow what you're saying. Pete > >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.
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.