Random Changes

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 System.Double value.

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 System.Security.Cryptography.RNGCryptoServiceProvider.

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 Next(int,int) overload.

Backward Compatibility

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.

About spouliot

Xamarin Hacker, Mono Contributor, Open Source Enthusiast with strong interests in Code Analysis, Cryptography and Security. Presently working on MonoTouch, previous projects were Moonlight and libgdiplus and a lot of the cryptographic work done on Mono.
This entry was posted in mono, monotouch, xamarin. Bookmark the permalink.

2 Responses to Random Changes

  1. Jed says:

    > If you depend on predicable random numbers

    Trying to understand… this breaks the Random(Int32) constructor?

    > Providing an identical seed value to different Random objects causes each instance to produce identical sequences of random numbers.

    • spouliot says:

      No. If you create two identical instances of, let’s say,, `a = Random(42);` and `b = Random(42);`, they will both give you the same pseudo random stream.

      If you saved the `a` stream with a old version of Mono and compare it to `b` produced by a new version of Mono then they will be different. That’s just like if you generated `a` with MS.NET and `b` with Mono (they also would be different).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s