Author: Robert Hyatt
Date: 17:30:49 11/18/04
Go up one level in this thread
On November 18, 2004 at 02:31:10, Russell Reagan wrote:
>On November 18, 2004 at 01:07:57, Daniel Shawul wrote:
>
>>>>Do you block the main(parent) thread when search is split? i have read ('m not
>>>>sure though) this may cause a problem but it seems to work fine for me.
>
>>>I don't. that way I just have four threads at all times, never blocked threads
>>>waiting on busy threads. That is a performance reducer... It is easier to use
>>>your idea, but a little less efficient.
>
>> I am not sure if i understnt this part. Blocking the main thread means one
>>less worker,so it can't be more efficient. but it may help for communication,for
>>example when a fail high is reported by a thread.
>
>
>He is saying (I think) that you could do this two ways. Let's say you're using a
>dual CPU machine.
>
>1. Main thread blocked (waiting for input), two search threads (3 threads total)
>2. Main thread (also a searcher), plus one extra search thread (2 threads total)
>
>The result is about the same. You have two search threads in both cases, but in
>case 1 you have an idle thread doing nothing 99% of the time. An idle thread
>doesn't do much, but it isn't free either. It still gets a turn just like the
>other threads. So he said it is "a little less efficient".
>
We are not quite on the same page. I wasn't thinking about I/O at all...
>I wonder how the multiprocess approach would compare to this multithreaded
>approach. What if you had (on a dual machine) a driver process which just reads
>from xboard (or whatever), and two worker processes doing the search. If you
>lower the priority of the driver process, does that help? Or is there any way to
>set thread priorities so an idle thread doesn't get a turn as often? Or does the
> OS already take care of this automatically?
If a thread blocks waiting for console input, it will _never_ run until the read
is satisfied and the thread is unblocked. You don't need to fiddle with
priorities at all.
>
>The multiprocess approach seems a little simpler to me, but for maximum
>performance it seems like multiple threads are the way to go. With multiple
>processes you also have some unecessary duplication of data, but that can be a
>good thing or a bad thing depending upon the circumstance I suppose.
with egtb it is a bad thing. Eugene's code is specifically written as
multi-threaded, so that the threads share the LRU EGTB buffers and you only have
one copy of anything in memory, including the egtb decompression indices which
can be huge.
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.