Use a parallel random generator (and possibly improve random number generation) about sferes2 HOT 11 CLOSED

A possible option to be thread-safe without mutex

auto& prng_engine()
{
  thread_local static std::random_device rd{};
  thread_local static std::mt19937 engine{rd()};
   
  return engine;
}

from sferes2.

The link to numbercrunch seems to be dead.

However, I have an expanded rand.hpp header, which runs on the boost random number generator (mersenne_twister), and which uses TBB_SCOPED_MUTEX to provide some form of being thread safe. The main reason to use the boost random number generator for me is that, given the same seed, the numbers produced by the build-in rand() function are not the same between our cluster and my laptop. My header also includes the option to serialize the state of the random number generator, such that resuming from a checkpoint can be deterministic.

It is probably not efficient, especially if many threads call the random number generator, but it may be an improvement over the current implementation.

I can make a pull request if you are interested.

from sferes2.

Hello @JoostHuizinga, in limbo we have developed a nice random generator: see here. It uses this nice C++ seed sequencing/entropy -- copy pasted here. As far as I remember it is thread-safe and does not need any initialization. It is not yet parallel though, but it can be done.

@jbmouret we could replace sferes random number generation with this? What do you think?

from sferes2.

Mmmh, so what I really want from my pseudo-random number generator is that it is deterministic. As in, I want to be able to rerun an experiment with a specified seed, and always get the exact same result (preferably also in the face of parallelism, though I haven't managed to do that). The reason would be that it makes debugging a lot easier. Would that still be possible?

from sferes2.

Would that still be possible?

I think we can make it work with fixed seed if chosen and random seed if not. I will try to port it to sferes and let you know how it goes.

from sferes2.

Actually, would it be possible to make the random number generator a modular part of Sferes? That way, I can switch between generators depending on the demands of the project. I added quite a bit of functionality to my own random number generator that is both highly specific, and not something that I would be willing to give up.

To be more specific, I added the ability to serialize the state of the random number generator, such that runs can be deterministic, even in the face of preemption, and I added the ability to push and pop random number generators from a stack, enabling a single core job to simulate a MPI job in terms of randomness.

from sferes2.

Yes, this would be a good improvement. For the parallel version, the issue
is that I did not find any way to get a thread-id from tbb (this may be
different now).

On Sat, Oct 22, 2016 at 10:19 AM Konstantinos Chatzilygeroudis <
[email protected]> wrote:

Hello @JoostHuizinga https://github.com/JoostHuizinga, in limbo
https://github.com/resibots/limbo we have developed a nice random
generator: see here
https://github.com/resibots/limbo/blob/master/src/limbo/tools/random_generator.hpp.
It uses this nice C++ seed sequencing/entropy
http://www.pcg-random.org/posts/simple-portable-cpp-seed-entropy.html
-- copy pasted here
https://github.com/resibots/limbo/blob/master/src/limbo/tools/rand_utils.hpp.
As far as I remember it is thread-safe and does not need any
initialization. It is not yet parallel though, but it can be done.

@jbmouret https://github.com/jbmouret we could replace sferes random
number generation with this? What do you think?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/sferes2/sferes2/issues/1#issuecomment-255514435, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFu8v7Abi1bMt9s4DNvq7fMJCdJT2mP3ks5q2cX3gaJpZM4Bzp0B
.

from sferes2.

I di not think you can have a deterministic parallel random number
generator, unless you make thread scheduling deterministic (which is not
what Linux does).

Le lun. 24 oct. 2016 21:53, Joost Huizinga [email protected] a
écrit :

Actually, would it be possible to make the random number generator a
modular part of Sferes? That way, I can switch between generators depending
on the demands of the project. I added quite a bit of functionality to my
own random number generator that is both highly specific, and not something
that I would be willing to give up.

To be more specific, I added the ability to serialize the state of the
random number generator, such that runs can be deterministic, even in the
face of preemption, and I added the ability to push and pop random number
generators from a stack, enabling a single core job to simulate a MPI job
in terms of randomness.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sferes2/sferes2/issues/1#issuecomment-255814818, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFu8v1Dg9pDbvc-UCmpkmcNaGlWjTV83ks5q3PB6gaJpZM4Bzp0B
.

from sferes2.

Well, you would need some kind of solution where each parallel task that requires randomness comes with its own (deterministic) seed, such that each thread can set the seed of its random number generator right before performing the task (which works, though I have only tried it with MPI). This obviously comes with significant overhead, and probably makes it such that small scale tasks (like mutations), can not be efficiently parallelized.

Which brings me to my real feature request, can the random number generator become a modular part of Sferes?

from sferes2.

Sure, it can. We should use a default value like in limbo.

Le lun. 31 oct. 2016 19:48, Joost Huizinga [email protected] a
écrit :

Well, you would need some kind of solution where each parallel task that
requires randomness comes with its own (deterministic) seed, such that each
thread can set the seed of its random number generator right before
performing the task (which works, though I have only tried it with MPI).
This obviously comes with significant overhead, and probably makes it such
that small scale tasks (like mutations), can not be efficiently
parallelized.

Which brings me to my real feature request, can the random number
generator become a modular part of Sferes?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sferes2/sferes2/issues/1#issuecomment-257331249, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFu8v6L7Qr5fx5KtJHgltDx0jcYe-qVkks5q5g3CgaJpZM4Bzp0B
.

from sferes2.

As @jbmouret marked, we can make it generic. So, @JoostHuizinga I will try to make a first draft of it in the following weeks and we will adapt accordingly to your/our needs.

from sferes2.