[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695743#comment-16695743
]
Alex D Herbert commented on RNG-57:
-----------------------------------
bq. I'm worried by the nextBoolean benchmark result
It seems to be as expected.
{{nextBoolean}} is now caching an {{int}} or {{long}} value and then using it
32 or 64 times to generate a boolean. So all the providers will be
approximately the same speed as the sequence generation is only called every
32nd or 64th call to {{nextBoolean}}. This basically levels the times.
The {{LongProviders}} are slower due to the use of {{long}} bit shifts instead
of {{int}}. I did experiment with allowing the {{LongProvider}} to cache a
{{long}} value split in half for two {{int}} values that could be used to
{{int}} bit shifts within {{nextBoolean}}. However this added overhead that
lowered performance below just using {{long}} bit shifts.
A good normalisation time would be to add a call to {{nextInt}} for the JDK
generator. This will show that all providers are fast for generating booleans.
I had a look at the the link you sent about the xoshiro benchmark of 100 runs.
They conclude that if an RNG fails all 100 runs then it is a systematic
failure. We do not have 100 runs but do have 9. There are the original 3 runs
for {{IntProvider}} and the 3 new runs you have done. I have also done 3 runs
for {{IntProvider}} but this is still pending. You have 3 runs for the new
implementation of {{LongProvider}} and I have 6. I am building a script to look
for systematic failures in this set of results.
A systematic failure of {{nextInt}} in a test would indicate that the bit
source output by the RNG is not suitable for caching. So any RNG that
systematically fails should be reverted back to the original code. This will
just require an {{@Override}} of the underlying implementation in the base
class. This of course depends on the test that is systematically failing.
However as described above the tests for LinearComplexity and RandomWalk are
demonstrations that the entire bit sequence is not sequentially random. To err
on the safe side it may be best to revert any RNG that systematically fails any
test. So this would include JDK, the MT and MT_64 (fails LinearComp) and the
new implementation of TWO_CMRES which always fails dieharder_dna. The xoshiro
site indicates that WELL_1024_A fails LinearComp as well.
I'll post the systematic failures report when the results are complete.
> 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)
