[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695792#comment-16695792
]
Gilles commented on RNG-57:
---------------------------
bq. The LongProviders are slower due to the use of long bit shifts instead of
int.
I vaguely imagined that could be the reason, but thought that, on a 64-bit
machine, they might have had the same performance.
bq. A good normalisation time would be to add a call to nextInt for the JDK
generator.
I'd prefer to keep the "same" reference, to compare the generators among
themselves.
bq. To err on the safe side it may be best to revert any RNG that
systematically fails any test.
I'm not sure: What ensures that the previous implementation to retrieve a
boolean from the underlying RNG is better?
Or, IOW, is there something that says that we cannot assume that the sequence
of bits is not uniform?
As a last resort, a user can perform a home-made combination of the RNG output
in order to get a more (?) random {{boolean}}.
It would be interesting to show an application failing because of lack of
randomness of the sequence returned by the current implementation...
bq. TWO_CMRES which always fails dieharder_dna
But you said that the test might be "suspect".
So, I'd rather keep the performance improvement, and trust the "BigCrush"
results (that show no systematic failure for TWO_CMRES).
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> -----------------------------------------------------------
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: core
> Reporter: Alex D Herbert
> Priority: Minor
> Labels: performance
> Fix For: 1.2
>
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
> {code:java}
> LongProvider provider = RandomSource.create(RandomSource.SPLIT_MIX_64);
> CachedLongProvider rng = new CachedLongProvider(provider);
> // Uses cached nextLong() 64 times
> rng.nextBoolean();
> // Uses cached nextLong() twice
> rng.nextInt();
> IntProvider provider = RandomSource.create(RandomSource.KISS);
> CachedIntProvider rng2 = new CachedIntProvider(provider);
> // Uses cached nextInt() 32 times
> rng2.nextBoolean();
> // This could be wrapped by a factory method:
> UniformRandomProvider rng = CachedUniformRandomProviderFactory.wrap(
> // Any supported source: IntProvider or LongProvider
> RandomSource.create(RandomSource...));
> {code}
> The implementation should be speed tested to determine the benefit for
> {{nextBoolean()}} and if {{nextInt()}} can be improved for {{LongProviders}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
