xoshiro265** uniform random number generator

[ralfkonrad]

Over the last couple of years the family of xoshiro / xoroshiro pseudorandom number generators has become popular and is being adopted in a couple of programming languages as the new default prng or at least as one of its optional ones. The main reason for this family is its performance, it is faster than the Mersenne twister.

Out of this family I have implemented xoshiro265** here which has a of period 2^256-1.

On my machine this implementation is approx. twice as fast in returning a double and still 20% faster for the BoxMullerGaussian.next() compared to Mersenne Twister.

Windows benchmark

--------------------------------------------------------------------------------------
Benchmark                                            Time             CPU   Iterations
--------------------------------------------------------------------------------------
xoshiro256StarStar.nextInt64();                  0.734 ns        0.732 ns    896000000
mersenneTwister.nextInt32();                      1.45 ns         1.44 ns    497777778

xoshiro256StarStar.next();                       0.734 ns        0.732 ns    896000000
mersenneTwister.next();                           1.46 ns         1.44 ns    497777778

xoshiro256StarStarBoxMullerGaussian.next();       9.06 ns         8.79 ns     64000000
mersenneTwisterBoxMullerGaussian.next();          11.6 ns         11.5 ns     64000000

xoshiro256StarStarCLGaussian.next();              19.7 ns         19.7 ns     37333333
mersenneTwisterCLGaussian.next();                 18.0 ns         18.0 ns     40727273

Ubuntu wsl benchmark

--------------------------------------------------------------------------------------
Benchmark                                            Time             CPU   Iterations
--------------------------------------------------------------------------------------
xoshiro256StarStar.nextInt64();                  0.677 ns        0.677 ns    999294783
mersenneTwister.nextInt32();                      1.48 ns         1.48 ns    464873186

xoshiro256StarStar.next();                       0.676 ns        0.676 ns   1000000000
mersenneTwister.next();                           1.47 ns         1.47 ns    467262894

xoshiro256StarStarBoxMullerGaussian.next();       9.03 ns         9.03 ns     76846821
mersenneTwisterBoxMullerGaussian.next();          11.1 ns         11.1 ns     63022694

xoshiro256StarStarCLGaussian.next();              8.15 ns         8.15 ns     84570989
mersenneTwisterCLGaussian.next();                 13.9 ns         13.9 ns     50685338

[ralfkonrad]

As a sidenote:

I'm testing the implementation against the reference implementation in https://prng.di.unimi.it/xoshiro256starstar.c by loading this c file unchanged in the Xoshiro256StarStarTest source file.

extern "C" {
#include "xoshiro256starstar.c"
}

A little bit odd perhaps?!

[coveralls]

coverage: 71.913% (+0.01%) from 71.902% when pulling 73d8568 on ralfkonrad:xoshiro_random_number_generator into ac9d996 on lballabio:master.

[pcaspers]

Great stuff! Would it be safer to use uint64_t instead of unsigned long long?

[ralfkonrad]

Would it be safer to use uint64_t instead of unsigned long long?

Haven't thought about it. 🤔

According to https://en.cppreference.com/w/cpp/language/types currently unsigned long long is defined as "at least 64" bits in the standard and all implementations (seem to) use 64 bits. But to be on the safe side probably uint64_t is the better choice.

[ralfkonrad]

@lballabio Little bit unsure about the SplitMix64 class here. Do we want it to be perhaps only an inner nested class in Xoshiro256StarStarUniformRng?

Not sure if it is a fully prng? Do we want to use its functionality outside of Xoshiro256StarStarUniformRng later on (separate class) or just for initialize xoshiro++ (inner nested)?

[lballabio]

I think it's ok here.

[ralfkonrad]

Okay, fine with me. But then it also needs to be tested.

[lballabio]

True. I wouldn't bother. It can be an inner class for the time being, or it can even be in an anonymous namespace in the cpp file.

[lballabio]

I don't think this is ever going to happen.

[ralfkonrad]

I fully agree, it's very, very unlikely.

I have "stolen" the idea from c#. Random number generator guys are probably extra paranoid careful. 😄

Personally I would keep it here as a reminder what theoretically might go wrong. But I leave it up to you.

https://github.com/dotnet/runtime/blob/a5ff66c825fab95898c84a57ff305bece82f352d/src/libraries/System.Private.CoreLib/src/System/Random.Xoshiro256StarStarImpl.cs#L33-L45

[lballabio]

I'd take it out. If the splitmix rng gives you 4 zeroes in a row, it's probably going to keep giving you zeroes.

[lballabio]

@ralfkonrad should we finalize this? I can do the last changes if you don't mind.

[ralfkonrad]

@lballabio Sorry, busy times plus Corona virus prevented making progress here. Do I have this weekend to finish it?

Or do you want to ensure to get it into next release? Then please go ahead.

[lballabio]

Sorry to hear that—are you ok now? In any case, don't use your weekend for this, I'll do the changes :)

[ralfkonrad]

Thanks @lballabio for picking this up. I would have probably over-engineered it in the approach I had in mind... 😃

I'm okay, but it took a while. Needed a lot of rest besides the regular work.