From: Ben Maurer <bmaurer@fb.com>
Date: Tue, 25 Feb 2014 02:37:24 +0000 (-0800)
Subject: Random number generator utilities for folly
X-Git-Tag: v0.22.0~683
X-Git-Url: http://plrg.eecs.uci.edu/git/?p=folly.git;a=commitdiff_plain;h=a9ba07eb94a5b85985859568789559882ad0e33d;hp=a9ba07eb94a5b85985859568789559882ad0e33d

Random number generator utilities for folly

Summary:
In looking at how people were using common/base/Random, I noticed
a number of issues with our current usage of random number generators

1) People would simply declare a RandomInt32 without seeding it. This
results in a predictable seed
2) We initialize a Mersenne Twister RNG from a single int32. This
causes us to have a more predictable starting sequence of numbers
3) People aren't consistently using thread-local RNGs
4) Many of the APIs lack consistency. For example random32 takes a
max parameter that is exclusive while uniformRandom32 uses inclusive
boundries

I'm hoping a better API can fix this. thread_prng implements the Generator
concept with result_type = int32. It isn't actually a random number generator,
but it uses a thread local to point to a real generator. An advantage
of this is that it can be used in existing APIs but that it doesn't expose
the implementation of the RNG via the header file. One thing that's a bit
weird about it is that if you copy the object across threads it could
cause an error.

The Random class provides utilities that take any type of random number
generator. This has the advantage of allowing the user to pass a RNG
meant for testing or a secure RNG based on /dev/random. Another advnatage
is if you're woried about the performance of TLS lookups, you can
cache a local thread_prng which memoizes the TLS lookup.

If available, we use a SIMD optimized MT API

Some open questions:

1) What functions should be in random
2) Should the default RNG be a 64 or 32 bit based RNG

Test Plan: Benchmark runs

Reviewed By: simpkins@fb.com

FB internal diff: D1181864
---