and by random changes I mean changes to
Random. Here’s what’s affected by the change:
The old algorithm used by Mono was not very efficient, even less on system where floating-point computations are slow. The new algorithm, JKISS, is faster and does not require floating-point math unless you ask for a
The requirement to use floating point, basically calling the protected
Sample method, was removed in .NET 2.0 – but never implemented in Mono.
E.g. Using Mono 3.2.3, JIT, x86_64 filling a one megabyte buffer 1024 times with random data took:
- 13 723 ms with the old code
- 7 244 ms with the new code
The difference is more visible on ARM devices where floating-point computation are not very fast. E.g. The same test built/executed with Xamarin.iOS 7.0, AOT, ARMv7+LLVM (iPod 4th gen running iOS7) took:
- 87 910 ms with the old code
- 28 658 ms with the new code
Beside not being very efficient the old algorithm had a short period (2^55-1) before it starts repeating the same pseudo random data stream. The new algorithm has a longer period (2^127).
That being said the new algorithm is not meant for cryptographic usage. In fact everything that does not require speed (i.e. a lot of random data) or predictability should use
Random API Q&A
Q: Does calling
new Random (...).Next () returns a random integer ?
A: Yes, but not 32 bits of randomness, i.e. the API returns a non-negative
System.Int32 value, so
[0,Int32.MaxValue]. The only way to get negative integers is to use the
If you depend on predicable random numbers, i.e. always the same random stream from the same seed (e.g. common in simulation software) then the change of algorithm will affect you.
In such case the best advice is to bundle your own random implementation inside your application (and, of course, have your own unit tests) to ensure no options/bugs interfere with your results. That way you’re shielded from platform and/or language changes.