Put FastRand into the core library

[craftworkgames]

When we combined the Mercury Particle Engine with MonoGame.Extended it came with a class called FastRand for generating random numbers really fast.

kosmonautgames noticed on the forums that this implementation is really good.

Turns out fastrand is 100x faster than the normal Random, given I initialize both beforehand and change the seed after every call.

Not only that, but when i tested both a million times against each other I calculated the average delta from 0.5 (which should be the expected value) and fastrand's delta was 2 magnitudes smaller. Wow. Am using that.

Unfortunately, at the moment the code is an internal static class in the MonoGame.Extended.Particles namespace. We should consider moving it up to the root namespace.

[Kosmonaut3d]

further testing would be needed, I am short on time for that.
It is possible I initialized wrongly and looking at the function it is hard to determine whether or not the results are really random enough and don't fall into recognizable patterns, I just tested with millions of calls.

[craftworkgames]

looking at the function it is hard to determine whether or not the results are really random enough

That's a good point, although, I guess it doesn't really matter that much if it's hard to tell. It depends on what you're using it for I suppose.

[Matthew-Davey]

Hey guys! I chose FastRand for Mercury because it's one of the faster RNG algorithms out there. The speed comes at the price of true 'randomness' though, there are certainly noticeable patterns & it compares quite unfavourably to other RNG algorithms in that respect. It's a really great choice in situations where speed is more desirable than a good random distribution, and a really poor choice when random distribution is important.

[craftworkgames]

Thanks for the info @Matthew-Davey. I suspected as much.

I think if we make it clear that FastRand is a faster alternative to normal Random and document the pros and cons as you've described here it makes sense to be part of the library. People can choose to use it if it makes sense for their situation.

One question though @Matthew-Davey. Why did you make it a static class?

I'm thinking if we pull it up into the core library, we should make it a normal class much like Random in the .NET framework. If people want to have multiple instances with different seed values I don't see any reason to stop them.

Something like:

var random = new FastRandom(mySeed);
var value = random.NextInteger();

The other benefit of this approach is that it might make sense to match the signature of the Random class so that it's a drop in replacement. We could add extension methods to Random for those that are missing. Not sure, I'm just thinking out loud here.

[Matthew-Davey]

Hi @craftworkgames, I made it static purely for speed. I anticipated random numbers being generated tens or hundreds of thousands times a second - and a static method call is marginally faster than an instance method call, especially if it can be inlined. There's only about 0.7 nanoseconds in it, but it adds up.

But then I was happy to trade away some fundamental OO principles in favour of speed - you might not want to make that same trade-off, especially for a general purpose library.

[craftworkgames]

Done.