pitdicker
commented
6 years ago Evaluation of Bob Jenkins small fast RNG.
This falls in the category of chaotic RNGs. It is reported to pass PractRand and BigCrush. There exist three variants: a 32-bit version, a 64-bit version, and 32-bit version with three rotations. License is public domain.
Speed and memory: Benchmarks from my pc, with Xorshift128/32 (current RNG in rand) as a baseline. x86_64:
test gen_u32_jsf32 ... bench: 2,229 ns/iter (+/- 1) = 1794 MB/s
test gen_u32_jsf64 ... bench: 2,312 ns/iter (+/- 4) = 1730 MB/s
test gen_u32_xorshift_128_32 ... bench: 1,082 ns/iter (+/- 2) = 3696 MB/s
test gen_u64_jsf32 ... bench: 3,078 ns/iter (+/- 3) = 2599 MB/s
test gen_u64_jsf64 ... bench: 2,311 ns/iter (+/- 5) = 3461 MB/s
test gen_u64_xorshift_128_32 ... bench: 2,638 ns/iter (+/- 23) = 3032 MB/sx86:
test gen_u32_jsf32 ... bench: 2,680 ns/iter (+/- 34) = 1492 MB/s
test gen_u32_jsf64 ... bench: 7,595 ns/iter (+/- 104) = 526 MB/s
test gen_u32_xorshift_128_32 ... bench: 1,475 ns/iter (+/- 60) = 2711 MB/s
test gen_u64_jsf32 ... bench: 3,838 ns/iter (+/- 63) = 2084 MB/s
test gen_u64_jsf64 ... bench: 7,661 ns/iter (+/- 73) = 1044 MB/s
test gen_u64_xorshift_128_32 ... bench: 4,591 ns/iter (+/- 59) = 1742 MB/sThe performance of jsf is not great. Note that I did not optimise it heavily. But the baseline Xorshift128/32 is not all that fast already, and jsf has in many situations only ~50% the performance of that.
The state size is 128 bits for the 32-bit variant, and 256 bits for the 64-bit variant.
Initialization and cycles. Officially a seed of only 32 bits is supported, or 64 bits for the 64-bit version. For this RNG short cycles are possible, even of length 1. For the 2^32 possible seeds of the 32-bit version, okay-ish tests are done to make ensure they all do not result in a short cycle (with short being 2^20 rounds).
PractRand includes a variant that can take 128 bits as seed. This opens up the implementation to short cycles, of which only 6 are known until know. But only cycles of length 0 are explored, there could be many more. So adjusting the initialization routine to take a larger seed does not seem wise.
There is some probabilistic guessing around 32-bit seeds and how long it takes for one seed to run into another seed, but it does not sound very convincing to me.
The shortest cycle is expected to be 2^94, but this is unproven.
Conclusion Based on performance, little theoretical background, and very small seeds jsf would not be a good choice for a default small RNG.
dhardy
vks
TheIronBorn
vigna
This are my personal requirements for picking a default small PRNG. It seems like we should have some set of requirements to apply to https://github.com/dhardy/rand/issues/52, beyond benchmarks. @dhardy, @vks: What do you think?
A user should not need to worry about:
This translates to the following requirements, in RNG terms:
Other qualities to look for are:
Speed and memory
This seems like a clear requirement. What differentiates small fast RNGs from cryptographic ones, is that they are very fast and / or use much less memory. Between a dozen and up to twenty instructions seem to be the norm. Also a state of about 16 bytes is usually enough, and using more memory is wasting.
Not consuming to many results
What should be the minimum amount of results that can be consumed? On today's hardware, a fast RNG can generate about 2^32 results in just 4 seconds. In most cases it is not reasonable to expect a process to do little else than generate random numbers, at least not without also requiring them to be cryptographically secure. With the exception of simulations maybe. 2^47 results take about a day to be generated. It seems anything that can generate a usable range close to 2^50 seems good enough.
Independently initialized RNGs having a chance of producing similar streams
Many RNGs have only one period. When you pick some random initial state, there is a chance to end up in the same range as the results of another generator. Lets take a period of 2^128, and 2^48 as an upper limit for the expected amount of used results. It then takes about 2^32 random initializations to have a chance of 1 in a million to repeat part of an already used stream. See this comment, although some numbers are off by a factor 1000. So a period of 128 bits seems like a minimum requirement.
An alternative is RNGs with a small period and support for multiple streams, like PCG (when using LCG as a base generator) and SplitMix offer. A period of only 2^64 is just about enough to have a chance of 1 in 2000 for one new RNG to end up within the stream of one other RNG. If the RNG has 2^63 possible streams like PCG, 2^27 initializations are possible before the stream has a change of 1 in 1000 of being the same. Conclusion: support for ~2^64 streams is just enough to make a period of ~2^64 good enough for worry-free initialization.
All the above relies on the RNG taking a seed that has as many bits as the log2 of the period, 128. If the RNG can only take less bits, initialization may still be worry-free if the RNG has a proven method to map that seed to a state that can not be in the usable range of another seed. An example could be initializing PCG with a fixed state, and a random u64 for the stream. With just a u64 it is possible to guarantee 2^22 initializations and still having a change of only 1 in a million of ending up in the same stream. I am not aware of any RNG that offers this, besides it being quite pointless.
For small chaotic RNGs it is not really possible to talk about periods. The sizes calculated above for periods should map to state sizes if the RNG is perfect. So the state of chaotic RNGs should be at least 128 bits. I am not yet clear on what guarantees are available for this category of RNGs. Especially how cycles effect the birthday problem when initializing.
Whether statistical biases it contains may or may not matter
The standard way to evaluate the statistical quality of RNGs is through test suites, with PractRand and the BigCrush test from TestU01 being the current state of the art.
Many small chaotic RNGs pass without problems, and are quite fast.
For RNG's with a fixed period the recipe seems to be: take a fast, low quality RNG as a base generator, and apply a permutation function. Only the simple base generators like Xorshift, LCG or a Wehl sequence fail quickly.
Whether a statistical biases of an RNG matter, depends on how the generated values get used. For many uses a little bias of patterns does not matter. On the other hand, when it does matter but someone does not realize so, it is very hard to notice. The values appear random after all.
RNGs that have a clear bill from BigCrush and PractRand can be used without worry. At least for all situations where there is no adversary that tries to predict the RNG, use cryptographic RNGs in such a case.
Not being trivially predictable
On the PCG blog a post about trivial predictability is worth a read. For some algorithms cryptographically secure PRNG are unnecessary heavy, while some difficulty predicting the next results is enough to deter adversaries. One example is randomized quicksort. Not being trivially predictable can be seen as a plus, but not a requirement.
Reproducable results also on architectures with a different endianness
Even more then cryptographic RNGs, simple RNGs are used in many situations that need reproducible results. Then endianness should not be a worry.
Reasonably good theoretical basis
If the RNG has at least some theoretical background, requirements like the period size or cycle length can be proven. I would say we need those guarantees for the RNG do be made a default in Rand. While a published paper is nice, even comments in the source code with math that makes sense seem good enough for me.
License that can be used in Rand.
Our licenses are MIT and Apache 2.0. For RNGs that means they should have compatible licenses, like MIT or public domain. Anything higher like BSD or GPL would need permission from the author.