Open NoureldinYosri opened 6 months ago
There was a past issue involving np.random
and multiprocessing. It may not be a concern with the present issue, but on the off chance that there are implications for this issue, it seemed worth pointing to it: #3717 ("Can't use cirq.Simulator() in a multiprocessing closure (unable to pickle)")
Is this issue still open @NoureldinYosri ? I would be interested if so
@kitsiosvas yes, it's still open. I have an old PR for this https://github.com/quantumlib/Cirq/pull/6566 you can take over it and continue this work if you want to.
Is your feature request related to a use case or problem? Please describe. We have several modules that spwan multiple threads for performance. each of those threads would be running a random operation using a random state or state. when those threads share the same
RandomState
the multithreading degenerate into sequential processing since those threads will be waiting on write operation of the random state.Describe the solution you'd like Start supproting
np.random.Generator
. This class provides the same API ofnp.random.RandomState
in addition to aspawn
function which can be used to create independent streams of random values. This will help when starting threads e.g.Describe alternatives/workarounds you've considered Before calling multithreads generate multipleseeds using a
np.random
orRandomState
. While this seems like what we are doing withnp.random.Generator.spawn
; it's actually different in that the radom seeds and hence the random sequences created will correlate. This means that when running the same operation (e.g. simulation) multiple times in parallel, the results will correlate.Additional context (e.g. screenshots) The cirq random number support is implemented in cirq-core/cirq/value/random_state.py
What is the urgency from your perspective for this issue? Is it blocking important work? P2 - we should do it in the next couple of quarters