Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sometimes faster rand(::Xoshiro, ::UnitRange{Int128}) #41067

Merged
merged 1 commit into from
Jun 10, 2021

Conversation

rfourquet
Copy link
Member

For Int128/UInt128 ranges, the default sampler provided by Random
is SamplerRangeFast; till now, this was optimized for a version
of MersenneTwister which produced natively 52 bits of entropy,
so if the range length was between 2^52 and 2^104, two 52-bits
words were generated (and used with rejection sampling).
But when the RNG can produce a 64-bits word in a fast way,
only one such word needs to be generated for a length
between 2^52 and 2^64: in this range, the new rand method
for SamplerRangeFast is about 35% faster.
Also, MersenneTwister can now generate UInt64 fast, but the two
methods are equally fast, so it was not changed for that RNG.

@rfourquet rfourquet added performance Must go faster domain:randomness Random number generation and the Random stdlib labels Jun 3, 2021
@rfourquet rfourquet changed the title sometime faster rand(::Xoshiro, ::UnitRange{Int128}) sometimes faster rand(::Xoshiro, ::UnitRange{Int128}) Jun 3, 2021
For Int128/UInt128 ranges, the default sampler provided by `Random`
is `SamplerRangeFast`; till now, this was optimized for a version
of MersenneTwister which produced natively 52 bits of entropy,
so if the range length was between 2^52 and 2^104, two 52-bits
words were generated (and used with rejection sampling).
But when the RNG can produce a 64-bits word in a fast way,
only one such word needs to be generated for a length
between 2^52 and 2^64: in this range, the new `rand` method
for `SamplerRangeFast` is about 35% faster.
Also, `MersenneTwister` can now generate `UInt64` fast, but the two
methods are equally fast, so it was not changed for that RNG.
@oscardssmith
Copy link
Member

Is this good to merge? Also, do we want to backport to 1.7?

@rfourquet
Copy link
Member Author

Is this good to merge?

On my side yes, the win32 CI failure seems unrelated.

@oscardssmith oscardssmith merged commit ecab430 into master Jun 10, 2021
@oscardssmith oscardssmith deleted the rf/rand/fast64 branch June 10, 2021 16:49
johanmon pushed a commit to johanmon/julia that referenced this pull request Jul 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:randomness Random number generation and the Random stdlib performance Must go faster
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants