Computer Chess Club Archives


Search

Terms

Messages

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

Author: David Blackman

Date: 00:24:19 05/26/00

Go up one level in this thread


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?
>
>Thanks for any comments.
>
>-Tom

Maybe this makes sense. If a thread finds a node already has a score in the
transposition table, it won't try to search it. One of the more promising
approaches to multi-threading is to do it just like this, with the transposition
table doing almost all the communication work, and each thread just doing a
search almost normally.

When you really get a multi-cpu, you might find it necessary to do some hacks to
prevent all the threads going down the same branch at once and duplicating work.
For instance, except for the "best" move you want to do first, at any node you
could slightly randomise the order to do moves.



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.