On Sun, Nov 01, 2009 at 11:04:25AM -0700, Brian Sheppard wrote:
> >The PRNG (pseudo random number generator) can cause the super-linear
> >speed-up, for example.
>
> Really? The serial simulation argument seems to apply.
But the serial simulation argument is just re-formulation of the
statement,
>The PRNG (pseudo random number generator) can cause the super-linear
>speed-up, for example.
Really? The serial simulation argument seems to apply.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/co
Darren Cook: <4aecdf3e.7010...@dcook.org>:
> Parallelization *cannot* provide super-linear speed-up.
>>>...
>>> The result follows from a simulation argument. Suppose that you had a
>>> parallel process that performed better than N times a serial program.
>>> Construct a new serial program that
Parallelization *cannot* provide super-linear speed-up.
>>...
>> The result follows from a simulation argument. Suppose that you had a
>> parallel process that performed better than N times a serial program.
>> Construct a new serial program that simulates the parallel process. There is
>> a c
On Fri, Oct 30, 2009 at 12:50 PM, Brian Sheppard wrote:
>>> Parallelization *cannot* provide super-linear speed-up.
>>
>>I don't see that at all.
>
> This is standard computer science stuff, true of all parallel programs and
> not just Go players. No parallel program can be better than N times a s
---
> From: computer-go-boun...@computer-go.org [mailto:computer-go-
> boun...@computer-go.org] On Behalf Of Brian Sheppard
> Sent: Friday, October 30, 2009 11:50 AM
> To: computer-go@computer-go.org
> Subject: [computer-go] MPI vs Thread-safe
>
> Back of envelope calculatio
On Fri, Oct 30, 2009 at 10:50:05AM -0600, Brian Sheppard wrote:
> >> Parallelization *cannot* provide super-linear speed-up.
> >
> >I don't see that at all.
>
> This is standard computer science stuff, true of all parallel programs and
> not just Go players. No parallel program can be better than
Back of envelope calculation: MFG processes 5K nodes/sec/core * 4 cores per
process = 20K nodes/sec/process. Four processes makes 80K nodes/sec. If you
think for 30 seconds (pondering + move time) then you are at 2.4 million
nodes. Figure about 25,000 nodes having 100 visits or more. UCT data is
ro
>> Parallelization *cannot* provide super-linear speed-up.
>
>I don't see that at all.
This is standard computer science stuff, true of all parallel programs and
not just Go players. No parallel program can be better than N times a serial
version.
The result follows from a simulation argument. Su
-
> boun...@computer-go.org] On Behalf Of Brian Sheppard
> Sent: Friday, October 30, 2009 7:49 AM
> To: computer-go@computer-go.org
> Subject: [computer-go] MPI vs Thread-safe
>
> >I only share UCT wins and visits, and the MPI version only
> >scales well to 4 nodes.
>
On Fri, Oct 30, 2009 at 07:53:15AM -0600, Brian Sheppard wrote:
> >I personally just use root parallelization in Pachi
>
> I think this answers my question; each core in Pachi independently explores
> a tree, and the master thread merges the data. This is even though you have
> shared memory on yo
>I only share UCT wins and visits, and the MPI version only
>scales well to 4 nodes.
The scalability limit seems very low.
Just curious: what is the policy for deciding what to synchronize? I recall
that MoGo shared only the root node.
___
computer-go
Sent from my iPhone
On Oct 30, 2009, at 9:53 AM, "Brian Sheppard"
wrote:
confirming the paper's finding that the play improvement is
larger than multiplying number of sequential playouts appropriately.
Well, this is another reason why I doubt the results from the Mango
paper.
Paral
>I personally just use root parallelization in Pachi
I think this answers my question; each core in Pachi independently explores
a tree, and the master thread merges the data. This is even though you have
shared memory on your machine.
>Have you read the Parallel Monte-Carlo Tree Search paper?
ter-go-boun...@computer-go.org [mailto:computer-go-
> boun...@computer-go.org] On Behalf Of Brian Sheppard
> Sent: Thursday, October 29, 2009 11:40 AM
> To: computer-go@computer-go.org
> Subject: [computer-go] MPI vs Thread-safe
>
> I have a question for those who have parallelized
It depends upon the scaling you want. Some of what you write seems to
imply that you are thinking about MCTS programs, while your questions
are also more general.
When we wrote SlugGo (one of the top programs a few years ago but
in hibernation now) we went with MPI. MPI lets you simulate as many
On Thu, Oct 29, 2009 at 12:40:26PM -0600, Brian Sheppard wrote:
> And now my question: what do you actually do: MPI, thread-safe, both, or
> something else?
Have you read the Parallel Monte-Carlo Tree Search paper? It sums up the
possibilities nicely. I personally just use root parallelization
(si
I have a question for those who have parallelized programs.
It seems like MPI is the obvious architecture when scaling a program to
multiple machines. Let's assume that we implement a program that has that
capability.
Now, it is possible to use MPI for scaling *within* a compute node. For
example
18 matches
Mail list logo
