[jira] [Comment Edited] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()

["Alex D Herbert (JIRA)" <ji...@apache.org>]

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

Alex D Herbert edited comment on RNG-57 at 11/16/18 4:43 PM:
-------------------------------------------------------------

bq. Could the "shade" plugin config be shared for making it easy to run all the examples that contain a main method

I'm not sure. I just wanted to get it to work within my local branch so Maven collected the dependencies from the local repo (i.e. ran my new code). I'm not sure if the final shaded jar can be the final output artifact that can be pushed up to Maven central. It contains all the dependencies and Maven central may want them to have signed source files. Maybe it can be pushed as a binary artifact. I'm not familiar with distributed binaries.

bq. Do you have a big cluster?

Yes. But it's probably not necessary. I'd have to get DieHarder and testu01 installed as loadable modules on the cluster. 2000 minutes is 33.3 hours. I can run the tests over the weekend on an old workstation with 12 cores.

I only have 4 {{LongProvider}} to test. The {{IntProvider}} have only changed {{nextBoolean}} and this is not tested. So 12 cores may be enough for 3 repeats of each test suite.



was (Author: alexherbert):
bq. Could the "shade" plugin config be shared for making it easy to run all the examples that contain a main method

I'm not sure. I just wanted to get it to work within my local branch so Maven collected the dependencies from the local repo (i.e. ran my new code). I'm not sure if the final shaded jar can be the final output artifact that can be pushed up to Maven central. It contains all the dependencies and Maven central may want them to have signed source files. Maybe it can be pushed as a binary artifact. I'm not familiar with distributed binaries.

bq. Do you have a big cluster?

Yes. But it's probably not necessary. I'd have to get DieHarder and testu01 installed as loadable modules on the cluster. 2000 minutes is 33.3 hours. I can run the tests over the weekend on an old workstation with 12 cores.

I only have 4 {{LongProvider}}s to test. The {{IntProvider}}s have only changed {{nextBoolean}} and this is not tested. So 12 cores may be enough for 3 repeats of each test suite.


> 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)