faster rand!(::MersenneTwister, ::UnitRange)

[rfourquet]

Ses commits message for details. The main performance improvement is for [U]Int128, e.g. a = zeros(Int128, 1000); rand!(a, Int128(1):Int128(10)) sees a 3x speed-up.
I plan also to unify further the 2 samplers for ranges, they look now very similar, but this wouldn't need to change the streams, so can be done in a non-breaking way later.

[rfourquet]

@nanosoldier runbenchmarks("random", vs=":master")

[ViralBShah]

@rfourquet You have a bunch of PRs open - and its unclear (at least to me) what is the right order to merge (all or some of them). Maybe good to discuss it on slack to co-ordinate and get the reviews going.

I think the first thing we should do is get things into stdlib, then apply any API changing PRs. The performance ones can be applied at a later point or in 1.1 as well.

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan

[rfourquet]

@ViralBShah Yes sorry to flood github with last minute work! I'm pushing those performance PR now because they are breaking, so would be good to have them for 1.0. Besides this one, I am preparing a last one today... but yes we can discuss on slack, thanks!

[rfourquet]

The benchmarks are consistent: while computing rand(1:10) for the SamplerRangeInt sampler, some work has been moved from rand(sampler) to the one-time work of computing the sampler itself (shown as RangeGenerator in the benchmark). So the biggest win is when computing many random values with the same sampler (my example with rand! in the OP), but even for the generation of only value, there are still modest performance improvement in general. I don't understand the regression with BitSet, on my machine it's a 2x or 3x regression only, which is acceptable, at least temporarily (RandomDevice() is not reproducible, so we can improve it with different algos in the 1.x timeframe). The reason is that SamplerRangeInt becomes here optimized for RNG producing Float64 natively, which is not the case of RandomDevice.

[rfourquet]

I will merge in few hours if no objection, in the meantime I will rebase the excision PR on top of this one, so that I have only one rebase to do. My other RNG PRs are easier to rebase after the excision and require a triage decision anyway.