Author: Bas Hamstra
Date: 07:26:13 11/11/99
Go up one level in this thread
On November 10, 1999 at 12:27:57, Pete Galati wrote: >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 I'm afraid we have a misunderstanding here :) I didn't mean the threads on this message board, but OS threads. Sort of paralel sub processes in a program. >> >>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.