Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: odd multithreaded search behavior--explanation?

Author: Dave Gomboc

Date: 16:58:26 05/27/00

Go up one level in this thread


On May 27, 2000 at 07:22:05, Rudolf Huber wrote:

>On May 26, 2000 at 02:49:55, Tom Kerrigan wrote:
>
>>I've been writing a multithreaded program. I'm running on 1 processor but my
>>program splits into 4 threads. So far, the threads don't communicate in any way,
>>so searches take exactly 4 times as long (not counting some overhead).
>>
>>But this evening I added a shared hash table, and now the threads=4 program is
>>only slightly slower (in terms of NPS and nodes/ply) than the threads=1 program.
>>
>>Is this some sort of mistake? I tried for almost an hour to prove that something
>>flakey is going on, but it seems to really go 4 times faster, even though the
>>threads don't communicate (except for the hash table). The PVs and scores that
>>the programs spit out are exactly the same, and the threads seem to be sharing
>>the work equally.
>>
>>Could this be some sort of side effect from running on 1 processor?
>
>Yes. I think the correct explanation for this was already given by others
>(One thread does some work, then the scheduler activates the next thread which
>is quickly moved (because of the TT entries) to the place where the other thread
>had to stop)
>
>A method to simulate a multiprocessor is to yield the processor after
>*every node* via "sched_yield()". That is POSIX. I do not know if
>Windows supports this.
>
>
>Rudolf Huber

FYI, NT/2000 has supported Posix for a long time.

Dave



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.