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 your machine.
Yes.
> You also have possibilities for largely lockless thread safety. For
> instance, the Intel architecture has atomic memory access instructions that
> allow lockless data safety. Remi Coulom published a paper on this subject.
>
> I am not even sure that "leaf" parallelization is really ruled out. For
> example, if GPU-based implementation works, then leaf parallelization must
> be reconsidered.
Fuego is probably prime example of well-working leaf parallelization,
using atomic memory operations and virtual losses; see the TR for
details and measurements.
> > similar to what you probably mean by MPI, though without resyncs
>
> MPI is "message passing interface" an industry standard API for supporting
> high performance computing.
>
> It is used for sharing data among multiple processes (that is, no shared
> memory). I recall that MoGo published that their massively scalable strategy
> is based on this approach.
Yes, I know what MPI is, I just wasn't sure what "_the_ MPI method"
would neccessarily be.
> >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.
> Parallelization *cannot* provide super-linear speed-up. The existence of
> super-linear speed-up proves that the underlying single-threaded program is
> flawed.
I don't see that at all. It seems quite logical to me that the results
could be better when threads vote on resulting move instead of spending
appropriately more in single search. I think the explanation that this
compensates better for various (short-term?) biases popping within the
UCT tree is logical.
It's some time since I last measured the multi-threading gains and I
made quite a lot of tweaks in the UCT exploration since, maybe I should
re-measure again; it's just that measuring this takes a lot of CPU
resources, thus is a pain. :-)
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
