Author: Tony Werten
Date: 10:31:19 12/01/03
Go up one level in this thread
On December 01, 2003 at 11:34:24, Robert Hyatt wrote: >On December 01, 2003 at 11:06:08, Tony Werten wrote: > >>On December 01, 2003 at 10:46:00, Robert Hyatt wrote: >> >>>On December 01, 2003 at 02:41:28, Tony Werten wrote: >>> >>>>When my masterthread is spinning, waiting for results from it's workers threads, >>>>how do I keep it from burning CPU time ? >>> >>>You have a couple of choices. But why is it important? You have two cpus. One >>>thread is doing something useful, the other is spinning. What is the problem? >>>The spinning thread has _zero_ effect on the running thread. IE in crafty I >>>have something like this: >>> >>>while (!work); >> >>I don't want to do it the way Crafty does :) ( Nothing personal) >> >>I have the idea I make the parallel search more effective if I let the >>splitpoint exist after splitting. > >That has nothing to do with sleeping or spinning. >In fact, I am not sure what it means. My "split points" always "exist >after splitting" that is why I call them "split points" :) > >> >>So when I search with 1 thread, I split, create (pick) 2 new threads let the >>splitpoint sleep, and have the 2 new threads search. > >You will have a _huge_ problem. A deep search will blow memory. Each thread >needs its own stack. Sleeping threads as well. I used this in my very >first pthread version of crafty, but the overhead for creating threads is _not_ >zero. It is very measurable and if you do it thousands of times, you incur a >lot of overhead in terms of time, not to mention you can certainly run out of >processes easily. It happened to me. I'm probably mixing up some terms. I'll try to explain. At start I want to create 2 * nr_processors threads (all capable of searching and splitting, so basicly a search class) and suspend them. Then when the 1st thread is ready to split, it itself enters a special function where it becomes a splitter, feeds (single) moves to the suspended threads, unsuspend them and waits for results to return. When a thread does that, the splitter hands out a new move etc. My idea was that when 1 thread is finished, it will go back to the splitpoint to help, rather then request another thread to share stuff. I think it will be more effective to share close to the root and not at a "random" point, wich will be closer to the leafs. Tony PS I'm only in the thinking stage. > > > > >> >>Tony >> >>> >>>work gets copied into cache. Until another thread writes to it, I spin on >>>local cache, no bus traffic whatsoever, and the instant I get work I start >>>to work on it the very next CPU cycle. If you block, you take a huge >>>performance hit to block and then unblock. >>> >>>> >>>>The apifunction sleep() doesn't some threadsafe, suspending the thread and >>>>having it resumed by the worker seems overly complicated. ( Accept maybe if I >>>>can use a callback function ) >>>> >>> >>>use a mutex-type lock that blocks when the lock is already set. Or if >>>using posix threads a "condition variable" will work better as multiple >>>threads can wait for the condition to be satisfied and all can proceed >>>when it is. But spinning is _the_ high-performance solution. >>> >>>IE I certainly hope you use spinlocks rather than blocking locks for >>>mutual exclusion/critical sections??? >>> >>> >>>>Any thoughts ? >>>> >>>>Tony
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.