[Numpy-discussion] PRNGs and multi-threading

Robert Kern robert.kern@gmail....
Fri Aug 21 11:12:06 CDT 2009


On Fri, Aug 21, 2009 at 17:48, Sturla Molden<sturla@molden.no> wrote:
>
> I am not sure if this is the right place to discuss this issue. However,
> I problem I keep running into in Monte Carlo simulations is generating
> pseudorandom numbers with multiple threads. PRNGs such as the Mersenne
> Twister keep an internal state, which prevents the PRNG from being
> re-entrant and thread-safe.

C extension function calls are always atomic unless if they release
the GIL. numpy.random does not. You have de facto locks thanks to the
GIL.

> Possible solutions:
>
>
> 1. Use multiple instances of PRNG states (numpy.random.RandomState), one
> for each thread. This should give no contention, but is this
> mathematically acceptable? I don't know. At least I have not seen any
> proof that it is.

As long as you use different seeds, I believe this is fine. The state
size of MT is so enormous that almost any reasonable use will not find
overlaps.

Although you don't really have re-entrancy issues, you will usually
want one PRNG per thread for determinism.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


More information about the NumPy-Discussion mailing list