On Saturday, July 19, 2014 8:52:11 PM UTC-4, James Delaney wrote:
>
> Since I also agree that Monte Carlo in parallel seems like it is 
> unavoidably "distributed", you should require each process to work on 
> non-overlapping substreams of the same stream.  I wonder (mainly for my own 
> purposes) if this pmap() implementation is all that "safe", in the 
> meantime, before a SFMT Jump is implemented.  
>
> That is, if you end up generating more than one rand() in a process, you 
> are not guaranteed that just by setting the seed will give you the same 
> results in each time you run it.
>
> In the meantime, might it be preferable to just generate all the rand()s 
> you are ever going to need, serially, ahead of time, put them in a 
> distributed array, and have your parallel processes work on their separate 
> pieces of the distributed array?
>

Hi Jim, that's a good point. As long as all of the calls to rand() happen 
in the `rvproducer` function I think it should be safe: the rvproducer code 
is only used in the main process and is wrapped in `@async` so it waits 
until the call finishes before executing again. It should produce exactly 
the same numbers in the same order as it would without the parallelization.

At least, that's my understanding of the pmap code. The `@sync` block in 
pmap starts here:

<https://github.com/JuliaLang/julia/blob/05aa8101d1a4ad5b504bb5f4c7f1dc49e82964f4/base/multi.jl#L1341>

and `getnext_tasklet()` is defined immediately before this block (line 
1325) and is what generates the next values from `Task(rvproducer)`. Those 
random variables are then passed to the other processes as an argument in 
line 1348. A secondary feature (that I didn't realize until just now) is 
that the random variables are stored if the call fails and are later 
retried. In my case, this code is all executed on a workstation so I don't 
expect individual processes to fail, but that could be nice on a shakier 
system.

Take all of this with a grain of salt. This is my first attempt at a 
serious project with Julia, so I might be misunderstanding the code base.

--Gray

Reply via email to