[ 
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634698#comment-16634698
 ] 

Alex D Herbert commented on RNG-57:
-----------------------------------

{quote}The benchmarking code is in class GenerationPerformance in module 
commons-rng-examples/examples-jmh.
{quote}
I was referring to updating the User Guide by rerunning the benchmark. If the 
changes go into the existing classes then there should not need to be any 
changes to the benchmark, just the reporting of the results.

The result here show that the system will be faster. But I've not tested if the 
system then performs worse on the DieHarder or BigCrush tests.
{quote}This should be a separate issue/commit.
{quote}
This is my understanding of the current tasks:
 * Pick the best method for {{nextBoolean}} (the remaining topic of this issue)
 * Add a cache for {{nextInt}} to the {{LongProvider}}
 * Add a cache for {{nextBoolean}} to the {{LongProvider}}
 * Add a cache for {{nextBoolean}} to the {{IntProvider}}

 * Update the {{Long/IntProvider}} to save part of the state for 
{{RestorableUniformRandomProvider}} to a {{byte[]}}
 * Modify all derived classes to add implementation specific state to the 
partial state {{byte[]}}
 * Ensure JUnit tests exist to test save/restore state part way through 
sampling booleans (and int) from a cached source of random bits

 * Rerun the performance speed tests for {{LongProvider}} and update the User 
Guide
 * Rerun the DieHarder and BigCrush tests for {{LongProvider}} and update the 
User Guide

Q. How should this be divided up into issues and PRs? I've added separations 
for suggested groupings.

> CachedUniformRandomProvider for nextBoolean() and nextInt()
> -----------------------------------------------------------
>
>                 Key: RNG-57
>                 URL: https://issues.apache.org/jira/browse/RNG-57
>             Project: Commons RNG
>          Issue Type: Improvement
>          Components: sampling
>    Affects Versions: 1.2
>            Reporter: Alex D Herbert
>            Priority: Minor
>              Labels: performance
>
> 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)

Reply via email to