[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627234#comment-16627234
]
Alex D Herbert commented on RNG-57:
---
Tried a first attempt at this. It is proving quite a challenge to speed it up.
Here are the results from 5 runs in JMH generating 10 samples with a
standard RNG or one wrapped with a cache.
I've implemented methods to speed up {{nextBoolean}} for all providers and
{{nextInt}} for {{LongProvider}}.
||Method||randomSourceName||cache||Score||Error||Relative||
|nextBooleanIntProvider|ISAAC|false|5600.46|435.03|1.000|
|nextBooleanIntProvider|ISAAC|true|3084.45|26.1|0.551|
|nextBooleanIntProvider|JDK|false|9734.99|31.55|1.000|
|nextBooleanIntProvider|JDK|true|2947.59|9|0.303|
|nextBooleanIntProvider|KISS|false|4799.21|240.71|1.000|
|nextBooleanIntProvider|KISS|true|3116.05|12.98|0.649|
|nextBooleanIntProvider|MT|false|5658.68|106.18|1.000|
|nextBooleanIntProvider|MT|true|3463.81|1212.98|0.612|
|nextBooleanIntProvider|MWC_256|false|4101.07|1579.94|1.000|
|nextBooleanIntProvider|MWC_256|true|3397.07|1627.95|0.828|
|nextBooleanIntProvider|WELL_1024_A|false|7418.54|3146.43|1.000|
|nextBooleanIntProvider|WELL_1024_A|true|3042.62|41.56|0.410|
|nextBooleanIntProvider|WELL_19937_A|false|8808.53|37.47|1.000|
|nextBooleanIntProvider|WELL_19937_A|true|3405.19|28.51|0.387|
|nextBooleanIntProvider|WELL_19937_C|false|9740.32|112.33|1.000|
|nextBooleanIntProvider|WELL_19937_C|true|2916.81|39.01|0.299|
|nextBooleanIntProvider|WELL_44497_A|false|9469.1|110.86|1.000|
|nextBooleanIntProvider|WELL_44497_A|true|2914.71|52.34|0.308|
|nextBooleanIntProvider|WELL_44497_B|false|9990.53|195.99|1.000|
|nextBooleanIntProvider|WELL_44497_B|true|2933.06|36.3|0.294|
|nextBooleanIntProvider|WELL_512_A|false|6431.45|173.8|1.000|
|nextBooleanIntProvider|WELL_512_A|true|3031.66|25.31|0.471|
|nextBooleanLongProvider|MT_64|false|7090.79|3296.42|1.000|
|nextBooleanLongProvider|MT_64|true|3029.21|19.46|0.427|
|nextBooleanLongProvider|SPLIT_MIX_64|false|3683.5|76.21|1.000|
|nextBooleanLongProvider|SPLIT_MIX_64|true|3086.58|105.96|0.838|
|nextBooleanLongProvider|TWO_CMRES|false|4802.98|76.5|1.000|
|nextBooleanLongProvider|TWO_CMRES|true|3078.19|11.66|0.641|
|nextBooleanLongProvider|XOR_SHIFT_1024_S|false|4618.21|12.35|1.000|
|nextBooleanLongProvider|XOR_SHIFT_1024_S|true|3068.69|1091.08|0.664|
|nextIntLongProvider|MT_64|false|6113.54|10.27|1.000|
|nextIntLongProvider|MT_64|true|4695.68|137.97|0.768|
|nextIntLongProvider|SPLIT_MIX_64|false|3513.22|34.72|1.000|
|nextIntLongProvider|SPLIT_MIX_64|true|3478.33|21.76|0.990|
|nextIntLongProvider|TWO_CMRES|false|4569.36|77.06|1.000|
|nextIntLongProvider|TWO_CMRES|true|4078.62|218.7|0.893|
|nextIntLongProvider|XOR_SHIFT_1024_S|false|4391.85|11.77|1.000|
|nextIntLongProvider|XOR_SHIFT_1024_S|true|3843.81|77.38|0.875|
The slow generators can be improved. The fast ones are more difficult.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627255#comment-16627255
]
Alex D Herbert commented on RNG-57:
---
For reference this is what I tried:
{code:java}
/**
* Wrap an IntProvider instance to enable fast provision of
* {@link UniformRandomProvider#nextBoolean()}.
*/
final static class CachedIntProvider
extends IntProvider
implements CachedUniformRandomProvider {
/** The underlying source of randomness. */
protected final UniformRandomProvider rng;
/**
* The cached value from a call to random UniformRandomProvider#nextInt().
*
* Provides a bit source for booleans.
*/
private int booleanSource; // Initialised as 0
/**
* The bit mask of the boolean source to obtain the boolean bit.
*
* The bit mask contains a single bit set.
* This begins at the least significant bit and is gradually shifted
* upwards until overflow to zero.
*/
private int booleanBitMask; // Initialised as 0
/**
* Create a new instance.
*
* @param rng the source of randomness
*/
CachedIntProvider(IntProvider rng) {
this.rng = rng;
}
@Override
public int next() {
// Delegate this
return rng.nextInt();
}
@Override
public boolean nextBoolean() {
if (booleanBitMask == 0) {
// Get the next value
booleanSource = next();
booleanBitMask = 1;
}
final boolean next = (booleanSource & booleanBitMask) == 0;
// Shift up. This will eventually overflow and become zero.
booleanBitMask <<= 1;
return next;
}
}
{code}
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627283#comment-16627283
]
Gilles commented on RNG-57:
---
Nice results!
Concerning the design partially shown, I don't understand the purpose of a
{{CachedUniformRandomProvider}} interface; the cache is an _implementation_
detail.
Either the we provide a high-level "adapter" (through a factory method):
{code}
final UniformRandomProvider rng =
RandomSource.cachingBoolean(UniformRandomProvider delegate) {
// Code which you proposed in the above comment: caching
// for "nextBoolean()" and delegating the other methods.
}
{code}
or we assume that caching will always be as fast or faster than discarding
data, and we implement it in the "core" module.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627396#comment-16627396
]
Alex D Herbert commented on RNG-57:
---
{quote}I don't understand the purpose of a CachedUniformRandomProvider interface
{quote}
It was a class private marker interface. ;)
I showed the method in case you could spot something silly. I am going to think
about it and try some variants.
Anyway the private classes implemented the marker interface to avoid double
wrapping. Here is the public API:
{code:java}
/**
* Factory class for wrapping instances of {@link UniformRandomProvider} to
cache
* values that can be reused to provision the interface methods.
*
* The int values generated by an {@link IntProvider} can be cached to enable
* fast provision of {@link UniformRandomProvider#nextBoolean()}.
* The long values generated by a {@link LongProvider} can be cached to
enable
* fast provision of {@link UniformRandomProvider#nextBoolean()} and
* {@link UniformRandomProvider#nextInt()}.
*/
public final class CachedUniformRandomProviderFactory {
// PRIVATE STUFF
/**
* Wrap the source of randomness.
*
* The returned provider will cache values from an {@link IntProvider} or
* {@link LongProvider} to enable fast provision of
* {@link UniformRandomProvider#nextBoolean()},
* and in the case of a {@link LongProvider} also
* {@link UniformRandomProvider#nextInt()}.
*
* If the source of randomness cannot be wrapped then it is returned
unmodified.
*
* @param rng the source of randomness
* @return the wrapped uniform random provider
*/
public static UniformRandomProvider wrap(UniformRandomProvider rng) {
// Avoid double wrapping
if (rng instanceof CachedUniformRandomProvider) {
return rng;
}
if (rng instanceof LongProvider) {
return new CachedLongProvider((LongProvider)rng);
}
if (rng instanceof IntProvider) {
return new CachedIntProvider((IntProvider)rng);
}
// Unknown implementation
return rng;
}
}
{code}
Anyway the API details can be sorted. My aim was to see if I could make it work.
Currently the {{LongProvider}} uses bit masking on longs. However the results
appear to show the {{nextInt}} is faster or equal for all {{LongProviders}}. So
I'm going to test a version that uses {{int}} bit masking for the
{{nextBoolean}}, having generated an {{int}} using a cached {{long}}.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16630299#comment-16630299
]
Alex D Herbert commented on RNG-57:
---
{quote}So I'm going to test a version that uses int bit masking for the
nextBoolean, having generated an int using a cached long.
{quote}
I've done this. It is not faster. The boolean is found using bit shift
operations. On a modern machine 64 bit operations are natively supported in the
register and as fast as 32 bit operations (AFAIK). So the source should always
use the native primitive type of the underlying RNG.
As for {{nextBoolean()}} I have tried a few methods and all fast bit shifting
variants seem quite similar. Some other methods are definitely worse. I do not
want to micro-benchmark this so am fine with this implementation:
{code:java}
/**
* Wrap a LongProvider instance to enable fast provision of
* {@link UniformRandomProvider#nextBoolean()}.
*/
static final class CachedLongProvider
extends LongProvider
implements CachedUniformRandomProvider {
/** The underlying source of randomness. */
private final UniformRandomProvider rng;
/**
* Provides a bit source for booleans.
*
* A cached value from a call to random
* {@link UniformRandomProvider#nextLong()}.
*/
private long booleanSource; // Initialised as 0
/**
* The bit mask of the boolean source to obtain the boolean bit.
*
* The bit mask contains a single bit set.
* This begins at the least significant bit and is gradually shifted
* upwards until overflow to zero.
*
* When zero a new boolean source should be created and the mask
* set to the least significant bit (i.e. 1).
*/
private long booleanBitMask; // Initialised as 0
/**
* Provides a source for ints.
*
* A cached value from a call to random
* {@link UniformRandomProvider#nextLong()}.
*/
private long intSource;
/** Flag to indicate an int source has been cached. */
private boolean cachedIntSource; // Initialised as false
/**
* Create a new instance.
*
* @param rng the source of randomness
*/
CachedLongProvider(LongProvider rng) {
this.rng = rng;
}
@Override
public long next() {
// Delegate this
return rng.nextLong();
}
@Override
public boolean nextBoolean() {
// Shift up. This will eventually overflow and become zero.
booleanBitMask <<= 1;
// The mask will either contain a single bit or none.
if (booleanBitMask == 0) {
// Get the next value
booleanSource = rng.nextLong();
// Set the least significant bit
booleanBitMask = 1;
}
// Return if the bit is set
return (booleanSource & booleanBitMask) != 0;
}
@Override
public int nextInt() {
// Directly store and use the long value as a source for ints
if (cachedIntSource) {
// Consume the cache value
cachedIntSource = false;
// Return the lower 32 bits
return (int) intSource;
}
// Fill the cache
cachedIntSource = true;
intSource = rng.nextLong();
// Return the upper 32 bits
return (int) (intSource >>> Integer.SIZE);
}
}
{code}
The same applies for {{IntProvider}} but just using an {{int}} as the boolean
source.
I'll run a new benchmark later on a free machine. For this test where the speed
differences can be small it helps to have a lot of repeats. I'm also finding
that the standard deviation can be quite high. I noticed because some
benchmarks use the same method and the standard deviation varies. This could be
due to the use of a underlying randomly seeded UniformRandomProvider which may
have different run time depending on the sequence. So I am also testing with
this which should run in linear time:
{code:java}
/**
* Simple test class to flip the bits in a long and return it.
*
* Flipping the bits ensures that repeat sampling booleans should be 50:50
* true:false.
*/
private static final class LongFlip extends LongProvider {
/** The value. This is flipped on each call to next(). */
private long value;
LongFlip(long seed) {
value = seed;
}
@Override
public long next() {
// Flip the bits.
value = ~value;
return value;
}
}
{code}
It serves as an optimistic lower limit on the speed of the default
implementation of {{nextBoolean()}}.
> 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
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16631801#comment-16631801
]
Alex D Herbert commented on RNG-57:
---
I tried a large benchmark using 100 runs in JMH.
The results for {{nextBoolean}} will need more work. They indicate that using
bit masking is not as fast as bit shifting for {{IntProvider.}}
Bit masking:
{code:java}
public boolean nextBoolean() {
// Shift up. This will eventually overflow and become zero.
booleanBitMask <<= 1;
// The mask will either contain a single bit or none.
if (booleanBitMask == 0) {
// Get the next value
booleanSource = rng.nextInt();
// Set the least significant bit
booleanBitMask = 1;
}
// Return if the bit is set
return (booleanSource & booleanBitMask) != 0;
}
{code}
against bit shifting:
{code:java}
public boolean nextBoolean() {
// Check the current shift.
// In multi-thread use the decrement can pass zero
// so use <= and not ==.
// Note: Current RNG are not thread safe though.
if (--discardShift <= 0) {
// Set shift to the size of an int
discardShift = Integer.SIZE;
// Get the next value
booleanSource = rng.nextInt();
// Check the most significant bit
return (booleanSource >>> 31) != 0;
}
// The discard shift is in the range 31 to 1
return ((booleanSource << discardShift) >>> 31) != 0;
}
{code}
The difference is significant at the P<0.001 level using a T-Test.
Using a {{LongProvider}} and the same ideas the bit masking is faster than the
bit shifting. So the different providers demand different methods.
This indicates that the 32 bit shifting is relatively faster than bit masking,
compared to 64 bit. I'm going to test it on some different machines.
For the {{LongProvider}} the {{nextInt}} results are clear: storing a value
from {{nextLong}} is optimal:
- Method 0 = No cache
- Method 1 = Cache the {{long}} from {{nextLong}}
- Method 2 = Cache an {{int}} from half of {{nextLong}}
||cacheMethod||randomSourceName||Method||Average||SD||Median||Rel.Average||Rel.Median||T-Test
P-value||
|nextIntLongProvider|FLIP|0|2214.4|18.23|2203.48|1.000|1.000|-|
|nextIntLongProvider|FLIP|1|2575.88|24.18|2545.56|1.163|1.155|1.36E-16|
|nextIntLongProvider|FLIP|2|2737.5|52.86|2657.27|1.236|1.206|-|
|nextIntLongProvider|MT_64|0|5909.35|65.69|5775.07|1.000|1.000|-|
|nextIntLongProvider|MT_64|1|4431.69|101.07|4257.25|0.750|0.737|0.219|
|nextIntLongProvider|MT_64|2|4389.76|45.33|4318.91|0.743|0.748|-|
|nextIntLongProvider|SPLIT_MIX_64|0|3568.26|64.09|3488.36|1.000|1.000|-|
|nextIntLongProvider|SPLIT_MIX_64|1|3268.32|75.49|3189|0.916|0.914|1.288E-13|
|nextIntLongProvider|SPLIT_MIX_64|2|3464.65|27.02|3451.67|0.971|0.989|-|
|nextIntLongProvider|TWO_CMRES|0|4496.06|73.06|4446.6|1.000|1.000|-|
|nextIntLongProvider|TWO_CMRES|1|3807.1|92.8|3657.3|0.847|0.822|0.905|
|nextIntLongProvider|TWO_CMRES|2|3811.41|79.68|3703.69|0.848|0.833|-|
|nextIntLongProvider|XOR_SHIFT_1024_S|0|4311.68|3.26|4309.63|1.000|1.000|-|
|nextIntLongProvider|XOR_SHIFT_1024_S|1|3559.53|59.25|3479.41|0.826|0.807|1.33E-5|
|nextIntLongProvider|XOR_SHIFT_1024_S|2|3724.05|105.79|3543.18|0.864|0.822|-|
Note:
* The FLIP random source just returns a single value for {{nextLong}} bit
flipping it each time.
* All results are faster than the native implementation.
* For MT_64 method 2 is faster but the T-Test P-value is is not significant
(0.22).
* For TWO_CMRES the P-value is not significant.
* For all other generators method 1 is faster and significant at the P=0.001
level.
> 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
>
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633328#comment-16633328
]
Gilles commented on RNG-57:
---
About this:
{code}
static final class CachedLongProvider extends LongProvider implements
CachedUniformRandomProvider {
{code}
I'm not sure whether it is your intended contribution to the codebase or just
test code for benchmarking.
Unless I'm missing something, I think that the public API should not expose
classes with "Cache" in their name.
Do your benchmarks show that the cache is always useful for performance (or to
never hurt)?
If so, it will be always "on" (an implementation detail).
If not, or there is some advantage to let the choice to the user (wrap or not),
then the public factory methods should be located in {{RandomSource}}, not as a
separate factory class.
In that case, the API must convey _what_ is provided (faster "nextBoolean()"),
not _how_ (caching of "nextInt()" or "nextLong()").
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633915#comment-16633915
]
Alex D Herbert commented on RNG-57:
---
{quote}I'm not sure whether it is your intended contribution to the codebase or
just test code for benchmarking.
Unless I'm missing something, I think that the public API should not expose
classes with "Cache" in their name.
{quote}
This is an internal class. It implements the private interface
{{CachedUniformRandomProvider}}.
I am currently still investigating things for benchmarking.
I now have speed results from 3 machines using Java 8:
- MacOS 10.13 : Intel Core i7 2.7GHz (laptop)
- Windows 7 : Intel Core i7-2600 3.4 GHz
- Linux Ubuntu 16.04 LTS : Intel(R) Xeon(R) CPU E5-1680 v3 @ 3.20GHz
The results for the {{nextInt}} for a {{LongProvider}} are all consistent.
Caching the long and returning the upper and lower 32 bits is the best method.
The results for the {{nextBoolean}} are variable across
architectures/platforms. This makes picking one method difficult and I have no
idea if the differences are due to chip architecture, the VM on the platform or
both. However out of the candidates they are all faster than not doing it.
So it may be best to just pick one that works the same way for {{IntProvider}}
and {{LongProvider}} (for improved maintainability). Or do a more rigorous
investigation of the speed using more architectures and JVMs.
{quote}Do your benchmarks show that the cache is always useful for performance
(or to never hurt)?
If so, it will be always "on" (an implementation detail).
{quote}
Yes.
Adding a cache by default for {{nextInt}} to the {{LongProvider}} would be
useful. I think this would be a more commonly used routine, e.g. for array
randomisation and to generate {{nextFloat}}. It also has a preferred
implementation that is clear from the tests I have done.
I see {{nextBoolean}} as more specialised. But it could be added with one of
the good implementations. Or the various implementations added to
{{commons-rng-examples}}, for instance to {{examples-sampling}}.
Adding this functionality as a default would require alterations to support
{{RestorableUniformRandomProvider}}. Each provider currently creates and
restores its own state as a {{byte[]}} within methods inherited from
{{BaseProvider}}:
{code:java}
protected byte[] getStateInternal();
protected void setStateInternal(byte[] state);
{code}
The change could alter the inheritance hierarchy so that implementations that
inherit from {{LongProvider}} and {{IntProvider}} no longer implement these
methods directly. Instead they are implemented at the level of
{{Long/IntProvider}} so that the state of the cached {{nextBoolean}} and
{{nextInt}} are saved there. The providers can then implement new methods to
get the {{byte[]}} representation of their state. This is then combined with
the {{byte[]}} representation of the cached values.
Note that adding the cache for {{nextInt}} to the {{LongProvider}} would
require updating the benchmark tests shown in the [User
Guide|https://commons.apache.org/proper/commons-rng/userguide/rng.html] for
Performance and Quality. This is not something I have yet investigated so is a
big change.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634651#comment-16634651
]
Gilles commented on RNG-57:
---
bq. This is an internal class. It implements the private interface
{{CachedUniformRandomProvider}}.
Internal is good but I think that my remark still hold: an _interface_ is for
specifying _what_ not _how_. :)
Anyway, this discussion is moot since IIUC the rest of your comment, the
performance is always better, and thus the existing classes will just be
modified to implement the cache.
bq. alterations to support {{RestorableUniformRandomProvider}}
Good catch.
This should be a separate issue/commit.
bq. alter the inheritance hierarchy
?
I get that part of the (complete) state should be handled in the base class and
part in the concrete subclass.
bq. updating the benchmark tests shown in the User Guide
The benchmarking code is in class {{GenerationPerformance}} in module
{{commons-rng-examples/examples-jmh}}.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635531#comment-16635531
]
Gilles commented on RNG-57:
---
bq. I was referring to updating the User Guide by rerunning the benchmark.
So did I.
Only the "Generating int values" table must be changed. Correct?
Perhaps add a table for "nextBoolean()"?
bq. I've not tested if the system then performs worse on the DieHarder or
BigCrush tests.
These tools test randomness in chunks of 32 bits. IIRC, the Java code that
bridges to them only calls the {{nextInt()}} method.
So the only impact would a bug in the implementation of the {{nextInt()}} cache
on a {{LongProvider}}; but there should be a unit test for that (rather than
rely on long-running external software).
bq. Rerun the DieHarder and BigCrush tests for LongProvider
That should not be necessary (cf. above).
Unless you suspect that some of the good results were because half of the
generated bits were thrown away... (?)
bq. How should this be divided up into issues and PRs?
Your suggested division looks fine.
I could have a look at the {{RestorableUniformRandomProvider}} part (unless you
absolutely want to do it).
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635714#comment-16635714
]
Alex D Herbert commented on RNG-57:
---
{quote}Perhaps add a table for "nextBoolean()"{quote}
Updating the performance benchmark to have nextBoolean is a good idea. When run
it should show that nextInt is faster than nextLong for the {{LongProviders}}
and nextBoolean is faster than nextInt or nextLong respectively.
{quote}That should not be necessary (cf. above).{quote}
I think it is necessary as the nextInt from the long provider only used the
lower 32-bits. It is possible these providers do not have as much randomness in
the upper 32-bits. The only way to know is to rerun the tests.
It is also then serves to document the randomness of nextLong, which was
previously missing from the User Guide.
{quote}Your suggested division looks fine.{quote}
OK. I will add support for caching values for nextBoolean and nextInt to the
abstract providers.
I've committed a few times to my local testing branch. I'll discard all this
and create a new branch with the changes for a PR as {{improvement-RNG-57}}.
_Unless you really want the history of the testing preserved somehow._ The
history basically contains a few different methods that were tested.
{quote}I could have a look at the RestorableUniformRandomProvider part{quote}
I'm fine with that since there are a few ways to do it. I'll leave it to you to
decide what fits the best with the design.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636050#comment-16636050
]
Gilles commented on RNG-57:
---
{quote}I think it is necessary as the nextInt from the long provider only used
the lower 32-bits. It is possible these providers do not have as much
randomness in the upper 32-bits. The only way to know is to rerun the tests.
{quote}
You are right indeed.
Given that is the stress test suites are quite time-consuming (especially "Big
Crush" of TestU01), I'll rerun them after the "feature-freeze". ;)
bq. Unless you really want the history of the testing preserved somehow.
I don't think that it is necessary; this JIRA report documents pretty well that
your analysis has been fairly thorough and led to the best alternative being
committed into the code repository.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636051#comment-16636051
]
Gilles commented on RNG-57:
---
{quote}I think it is necessary as the nextInt from the long provider only used
the lower 32-bits. It is possible these providers do not have as much
randomness in the upper 32-bits. The only way to know is to rerun the tests.
{quote}
You are right indeed.
Given that is the stress test suites are quite time-consuming (especially "Big
Crush" of TestU01), I'll rerun them after the "feature-freeze". ;)
bq. Unless you really want the history of the testing preserved somehow.
I don't think that it is necessary; this JIRA report documents pretty well that
your analysis has been fairly thorough and led to the best alternative being
committed into the code repository.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636686#comment-16636686
]
Alex D Herbert commented on RNG-57:
---
After some more benchmarking I cannot categorically state that one method is
preferred over the other for speed. However the method using bit masking (see
earlier post) improves performance for both Int and Long providers across all
tested platforms. This method is intuitive and should be maintainable in the
future.
Here are the results for {{nextBoolean}}:
||RNG||Test||Relative||
|ISAAC|Linux|0.552|
|ISAAC|Mac|0.493|
|ISAAC|Windows|0.519|
|JDK|Linux|0.281|
|JDK|Mac|0.266|
|JDK|Windows|0.283|
|KISS|Linux|0.552|
|KISS|Mac|0.578|
|KISS|Windows|0.493|
|MT|Linux|0.476|
|MT|Mac|0.476|
|MT|Windows|0.380|
|MT_64|Linux|0.767|
|MT_64|Mac|0.751|
|MT_64|Windows|0.767|
|MWC_256|Linux|0.698|
|MWC_256|Mac|0.689|
|MWC_256|Windows|0.700|
|SPLIT_MIX_64|Linux|0.872|
|SPLIT_MIX_64|Mac|0.909|
|SPLIT_MIX_64|Windows|0.872|
|TWO_CMRES|Linux|0.854|
|TWO_CMRES|Mac|0.825|
|TWO_CMRES|Windows|0.854|
|WELL_1024_A|Linux|0.387|
|WELL_1024_A|Mac|0.412|
|WELL_1024_A|Windows|0.363|
|WELL_19937_A|Linux|0.317|
|WELL_19937_A|Mac|0.350|
|WELL_19937_A|Windows|0.311|
|WELL_19937_C|Linux|0.300|
|WELL_19937_C|Mac|0.330|
|WELL_19937_C|Windows|0.276|
|WELL_44497_A|Linux|0.294|
|WELL_44497_A|Mac|0.328|
|WELL_44497_A|Windows|0.306|
|WELL_44497_B|Linux|0.297|
|WELL_44497_B|Mac|0.322|
|WELL_44497_B|Windows|0.273|
|WELL_512_A|Linux|0.432|
|WELL_512_A|Mac|0.426|
|WELL_512_A|Windows|0.363|
|XOR_SHIFT_1024_S|Linux|0.813|
|XOR_SHIFT_1024_S|Mac|0.831|
|XOR_SHIFT_1024_S|Windows|0.813|
Test
- Linux Ubuntu 16.04 LTS : Intel Xeon E5-1680 v3 3.2GHz : OpenJDK 1.8.0_181
- MacOS 10.13 : Intel Core i7 2.7GHz (laptop) : Java 1.8.0_131
- Windows 7 : Intel Core i7-2600 3.4 GHz (desktop) : Java 1.8.0_171
I will set up a PR to add the method to the Int and Long providers.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636788#comment-16636788
]
ASF GitHub Bot commented on RNG-57:
---
GitHub user aherbert opened a pull request:
https://github.com/apache/commons-rng/pull/11
RNG-57: Cache values for nextBoolean() and nextInt()
AbstractIntProvider has been updated to cache a value for nextBoolean().
AbstractLongProvider has been updated to cache a value for nextBoolean()
and nextInt().
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/aherbert/commons-rng improvement-RNG-57
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-rng/pull/11.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #11
commit 58afa68ebef161fa938c06ceed6bc324e8367e4a
Author: aherbert
Date: 2018-10-03T10:54:37Z
RNG-57: Cache values for nextBoolean() and nextInt()
AbstractIntProvider has been updated to cache a value for nextBoolean().
AbstractLongProvider has been updated to cache a value for nextBoolean()
and nextInt().
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636813#comment-16636813
]
Alex D Herbert commented on RNG-57:
---
The changes to implement the cache in {{IntProvider}} and {{LongProvider}}:
[PR 11|https://github.com/apache/commons-rng/pull/11]
Travis has just told me this failed. This is due to 'Too many failures ...' in
the testing of the different providers. This is for code I have not touched as
the tests are for IntProvider.nextInt() and LongProvider.nextLong(). I assume
they would pass on repeat since they are random. Note that different provider
tests failed for JDK 7, 8 and 9 due to randomness.
There are also a failures for ProvidersCommonParametricTest.testStateSettable().
This has not been fixed and was intended to be part of a different PR. However
it may be best implemented together to make the PR atomic.
This will take a bit of time.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636816#comment-16636816
]
ASF GitHub Bot commented on RNG-57:
---
Github user aherbert commented on the issue:
https://github.com/apache/commons-rng/pull/11
This failed. This is partly due to 'Too many failures ...' in the testing
of the different providers. This is for code I have not touched as the tests
are for IntProvider.nextInt() and LongProvider.nextLong(). I assume they would
pass on repeat since they are random. Note that different provider tests failed
for JDK 7, 8 and 9 due to randomness.
There are also a failures for
ProvidersCommonParametricTest.testStateSettable().
This has not been fixed and was intended to be part of a different PR (see
[RNG-57](https://issues.apache.org/jira/browse/RNG-57?focusedCommentId=16635531&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16635531)).
However it may be best implemented together to make the PR atomic.
This will take a bit of time.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636981#comment-16636981
]
Gilles commented on RNG-57:
---
{quote}There are also a failures for
ProvidersCommonParametricTest.testStateSettable().
{quote}
I haven't looked at the error yet, but tests related to the saving/restoring
the state were expected to fail, weren't they?
Until the whole state is taken into account...
{quote}However it may be best implemented together to make the PR atomic.
{quote}
As you wish; but try to make incremental commits, separating the new "state
saving" logic from the cache feature, as much as possible.
Or let me the chance to implement the latter. ;)
I may have some time tomorrow; but if you want to do it today, no problem...
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16637066#comment-16637066
]
Alex D Herbert commented on RNG-57:
---
{quote}Or let me the chance to implement the latter.{quote}
I was just thinking the same. If the state saving is separated into the
abstract class and derived classes then this can be committed without error.
My PR then just needs to be updated (and verified) when master has moved on. So
I'll leave it until you have had a look at the state issue.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638968#comment-16638968
]
Gilles commented on RNG-57:
---
bq. when master has moved on
Please review the changes made for RNG-58.
All tests pass, but there isn't any actual state yet other than at the bottom
of the hierarchy...
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639023#comment-16639023
]
Gilles commented on RNG-57:
---
Nit about PR 11: No need to insert paragraph formatting tags (...) in
the Javadoc; in particular for private fields or methods (that won't appear in
the generated doc for the web site). IMO, the tags are visual noise that makes
it more difficult to read the source file.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639951#comment-16639951
]
Alex D Herbert commented on RNG-57:
---
{quote}No need to insert paragraph formatting tags (...) in the
Javadoc{quote}
Thanks for pointing that out. I add them everywhere out of habit.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1663#comment-1663
]
Alex D Herbert commented on RNG-57:
---
{quote}Please review the changes made for RNG-58.
{quote}
Nice modifications. I noticed that the {{BaseProvider}} has the signature:
{code:java}
protected byte[] composeStateInternal(byte[] state,
byte[] parentState) {
{code}
but the javadoc order for {{parentState}} and {{state}} are reversed. So I
assume you originally wrote it the other way around then swapped them. With no
state from the parent it wouldn't be detected in a test.
Suffice to say it doesn't work as is and I had to swap them back to:
{code:java}
protected byte[] composeStateInternal(byte[] parentState,
byte[] state) {
{code}
This is the simplest change to get things working. However the order in the
combined state is state+parentState so logically the arguments should be state
and parentState. But all the sub-classes do this:
{code:java}
return composeStateInternal(super.getStateInternal(),
state);
{code}
So parent should be first. It is also documented to work this way.
So I've just added some comments in the code that the order is state+parent
when combining and splitting.
The test for {{ProvidersCommonParametricTest.testStateSettable}} passes. So the
combining and splitting of the state is working.
I am now getting some failures in {{ProvidersCommonParametricTest}} due to
randomness.
The failures are always the same. Each RNG is built using a fixed seed and I
assume JUnit is running the tests in the same order.
However the changes to cache calls from {{next}} (either {{int}} or {{long}})
means that the sequence that is tested after the first call to {{nextBoolean}}
for an {{IntProvider}}, or the first call to {{nextBoolean/nextInt}} for an
{{LongProvider}} is different. These are the failures:
{noformat}
[ERROR] Failures:
[ERROR]
ProvidersCommonParametricTest.testUniformNextIntegerInRange:165->checkNextIntegerInRange:400->checkNextIntegerInRange:420->checkNextInRange:552
org.apache.commons.rng.core.source32.MultiplyWithCarry256: Too many failures
for n = 1834691456 (11 out of 500 tests failed)
[ERROR]
ProvidersCommonParametricTest.testUniformNextLongInRange:180->checkNextLongInRange:438->checkNextInRange:552
org.apache.commons.rng.core.source64.XorShift1024Star: Too many failures for n
= 4611686018427387902 (11 out of 500 tests failed)
{noformat}
- MultiplyWithCarry256 is an {{IntProvider}} and so the method {{next(int)}}
is unchanged. The failures are due to the state of the sequence being shifted
after a call of nextBoolean.
- XorShift1024Star is a {{LongProvider}} and the method {{next(int)}} has been
changed. The failures may actually be due to the loss of randomness from using
the using the upper and lower bits from the long as separate {{int}} samples.
However both tests only fail with 11/500 (p=0.022) which is 1 failure above the
critical p-value of 0.02.
I've pushed to the same PR branch so you can view the changes.
Q. What to do to fix this?
- Change the fixed seed for each of the failing providers until it works.
- Change the critical p-value.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640009#comment-16640009
]
ASF GitHub Bot commented on RNG-57:
---
Github user aherbert commented on the issue:
https://github.com/apache/commons-rng/pull/11
[RNG-58](https://issues.apache.org/jira/browse/RNG-58) addresses the
setting of the state, allowing state to be stored at any level of the hierarchy
below `BaseProvider`.
This PR has been updated to use that functionality.
The build now fails due to the randomness of testing.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640345#comment-16640345
]
Gilles commented on RNG-57:
---
bq. So parent should be first. It is also documented to work this way.
Actually not, as it would be confusing since in the code the "local" state
comes first.
bq. So I've just added some comments in the code that the order is state+parent
when combining and splitting.
Thanks but it is the Javadoc example that needed fixing.
And all the calls in the implementations...
As you noted, the code in {{BaseProvider}} concatenates "local" + "parent", and
is pretty self-documenting.
I'll make a separate commit to fix.
Sorry for the mix-up!
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640357#comment-16640357
]
Gilles commented on RNG-57:
---
Please rebase your changes on the current "master" (sorry).
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640363#comment-16640363
]
Alex D Herbert commented on RNG-57:
---
I also noticed that {{BaseProvider}} returns an empty array in
{{getStateInternal}} but the method to concatenate them only checks for null.
So the null check could be updated to:
{code:java}
if (parentState == null || parentState.length == 0) {
return state;
}
{code}
A quick check with:
{noformat}
mvn test jacoco:report
{noformat}
shows that the parentState == null is never hit at the moment.
WDYT?
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640369#comment-16640369
]
Gilles commented on RNG-57:
---
bq. Each RNG is built using a fixed seed
IIRC, I did this to avoid a circular dependency between {{commons-rng-core}}
and {{commons-rng-simple}}; but I think that a random seed would be preferable,
even if the test would then sometimes fail.
Perhaps a circular dependency in the {{test}} area is acceptable (?).
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640372#comment-16640372
]
Gilles commented on RNG-57:
---
bq. shows that the parentState == null is never hit at the moment.
Indeed. I changed that yesterday but forgot to {{git push}}...
It's now in "master".
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640375#comment-16640375
]
Alex D Herbert commented on RNG-57:
---
bq. IIRC, I did this to avoid a circular dependency between commons-rng-core
and commons-rng-simple;
For a test you can use anything to create the seed, i.e. another library. The
maven dependency can be scoped to test.
But that adds complexity so just use java.util.Random to get a not so random
seed. Or SecureRandom to get a very random one.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640379#comment-16640379
]
Alex D Herbert commented on RNG-57:
---
bq. Please rebase your changes on the current "master" (sorry).
Done. It still fails due to randomness on this machine on
{{MultiplyWithCarry256}} with {{nextInt}}.
I say this machine since it is now my laptop. I noticed that the errors on
Travis were different for JDK 7 than with 8 & 9.
I'm using JDK 8. So the JUnit tests must get run in a different order depending
on the JDK and/or the platform.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640486#comment-16640486
]
Gilles commented on RNG-57:
---
There are too many things in PR 11: it should only contain the additions to
{{LongProvider}} and {{IntProvider}} and their associated unit tests.
For the failures, I think that the least problematic change would be to select
another seed. We can always revisit later the common infrastructure of the
unit tests.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640697#comment-16640697
]
ASF GitHub Bot commented on RNG-57:
---
Github user aherbert commented on the issue:
https://github.com/apache/commons-rng/pull/11
This branch has too many commits. I am closing the PR and will create a new
one from master.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640698#comment-16640698
]
ASF GitHub Bot commented on RNG-57:
---
Github user aherbert closed the pull request at:
https://github.com/apache/commons-rng/pull/11
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640712#comment-16640712
]
Alex D Herbert commented on RNG-57:
---
I've closed the PR and repeated the changes in a new branch.
Do you want me to experiment with different seeds in {{ProvidersList}} until
the tests pass? A quick change to add a few more numbers to the MWC_256 seed
has fixed the test locally.
Unfortunately travis may still fail as it runs JDK 7, 8 and 9 and locally
passing tests on one machine may not transfer.
I am wondering if the {{ProvidersList}} should make a better attempt at
creating a full length seed. Perhaps this will make the test more robust.
Previously the RNGs that failed were:
||RNG||Native seed||Test seed||
|Well1024a|int[32]|int[3]|
|XorShift1024Star|long[16]|long[3]|
|MersenneTwister|int[624]|int[3]|
|MultiplyWithCarry256|int[257]|int[4]|
So the seed could be made full length for each provider.
Although each provider does expand the seed to the full length using a
scrambling method the original seed could be improved using numbers that have
more complete coverage of the bit size of the native seed type. The numbers
typed into the test are quite short and may not contribute enough entropy.
Using java.util.Random is an option. However I am not sure the implementation
is guaranteed to return the same sequence for the same seed for all future JDK
versions. So hardcoding the seed is probably better.
WDYT?
- Repeat the PR as is with it failing and leave {{ProvidersList}} for a
different change?
- Update the PR to include better seeds for {{ProvidersList}}
Applying the code changes is easy. I can create a temp branch to try different
seeds until it passes on Travis then formulate an atomic PR.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640722#comment-16640722
]
Alex D Herbert commented on RNG-57:
---
Wow that test is hard to get to pass.
I just tried this using a 1024 byte random seed for all tests. The seed is
stored as a string and decoded using Commons Codec:
{code:java}
public class ProvidersList {
/** List of all RNGs implemented in the library. */
private static final List LIST =
new ArrayList();
/** List of 32-bits based RNGs. */
private static final List LIST32 =
new ArrayList();
/** List of 64-bits based RNGs. */
private static final List LIST64 =
new ArrayList();
/**
* Provide a random byte seed encoded as a hex string (length must be even).
*
* 1024 bytes = 2048 hex characters. This provides 128 longs and 256
integers.
*/
private static final String HEX_SEED =
"75d1fb070512e503f9635706318f2dabbd6e2120addbd50c8ff8272654f3082c"
+ "edf244845db03415bf661051d9a487c622b6411a6773596f459465c72d59e870"
+ "c6bd90089a6fb7294d3beea8feba7d8307745cbd1233b6f85ff0294f87483d9a"
+ "ea77939ced0eb7e41617b52ac5a0d32d49c456e7b4c2485bd8d8be990f626458"
+ "86c5194aa34eb1f83efc38808ebf1fcd813667f88e7a76191dee40f662968a8c"
+ "71cf6493497ad77e00efbb59bfbf9b7664f8c32b4f5f29064329174bbce4870d"
+ "bb6bfd683415428d1c2c76eacca237df7119ecf1e6eac7cc97f3548bb10255b0"
+ "74a44010fa4811fc622104cea4ca045c674bbaa65f2273879301c4902bdb2f72"
+ "b9e7b1f5414704bb240a6a4d490a39739a557338b1e58cb5e81d8157172482d0"
+ "407795dffa92caacf3db3c848e1f2962bd5e8ddd4691a49779eea65d38d9d584"
+ "9b7ea054677618a9f56893877c34bb5d928308c8be19e07627b646cc743d0ddf"
+ "44757e64c1268eeb5e88a55a718f4fb9ba313b68ab1729efff6989192c95a2d8"
+ "42292766523b8d03e2dc10b1157b45909ecf239e59a4334eafa0b48c39a980dc"
+ "0f4238dcdaf306a57a29758a23f992eb7d13439ad982ec5a83aac630a31e05a3"
+ "0724a7babb5ebbcc00144c90a9a79c976f7cdd516fd94a432e815e3aeffdccb0"
+ "515a409dcfe7f492c0015234706eff83eda607cf76ec9b0f74a6d3050fc1f469"
+ "42475ef814847c5053fffa1e5d732f8954f1d6a678ce88e19ca92f6d5b945ac3"
+ "f872c05f3481659f27f570f3d387e1a75bc17408d454c6b4190d78c6aeac2cc5"
+ "0d8042b373ca4f149e32b81933076c23c2e3e36d7ba29079dd0e605b617c6378"
+ "ee714b66cb0959f4ff127cf1f0ad42919780fc51174c8818a630d32bfca5b03c"
+ "698e63f774dc979a27dddc795d5146ab49baf32b79014bf2e533e82d663da5d8"
+ "42d57fbe1e1a270ccb17c6daf1ea6cad92a4f6b311dee23f5362106d0cda8130"
+ "ae391221e790a610b6bbd9f64bf988783a5fde4b0d3504a417aac0a1a70b8c4a"
+ "6395ae21e41c1efa31a37737b15d4c8c77909306c41028ea9e04d7f0141b2c13"
+ "d6e0d20a0df619b575eeb1c6aebd7f03b56060c4bf4cf1fdcea3f0a9d03d8e61"
+ "54d8d9c92fb5eba0f3f3ddaa82190c766d0c5acdc52b29cf4dfe45731434e443"
+ "8652301bbba00bad464a467abfe46283adfd05bffad627171140fbbbf6d080a0"
+ "9971e17c0771abe6e354eb2e3330449080cf2133ac5b4a4240c357c50b5b144b"
+ "7c8fd76935fbb2741b4def4ea7f2455d794e600a121d16172fc4c951ba152b89"
+ "99232249e456e47ed12270959e2d5ae97a73b6d448a958e9c644e51af7199ce8"
+ "ed6a277f88a599093214e70832fe52ebf99862ce2e59da603a909075c238a8cf"
+
"42f359f7d269716bf53fcd10e04f3149b55dafce78cc8d5f2753723b1a202d86";
static {
try {
// Decode the seed into bytes.
byte[] bytes = Hex.decodeHex(HEX_SEED);
// Create long seeds
DataInputStream dis = new DataInputStream(new
ByteArrayInputStream(bytes));
long[] longSeed = new long[bytes.length / 8];
if (longSeed.length < 10) {
throw new Exception("Not enough seed bytes");
}
for (int i = 0; i < longSeed.length; i++) {
longSeed[i] = dis.readLong();
}
dis.close();
// Create int seeds
dis = new DataInputStream(new ByteArrayInputStream(bytes));
int[] intSeed = new int[bytes.length / 4];
for (int i = 0; i < intSeed.length; i++) {
intSeed[i] = dis.readInt();
}
dis.close();
// "int"-based RNGs.
add(LIST32, new JDKRandom(longSeed[0]));
add(LIST32, new MersenneTwister(intSeed));
add(LIST32, new Well512a(intSeed));
add(LIST32, new Well1024a(intSeed));
add(LIST32, new Well19937a(intSeed));
add(LIST32, new Well19937c(intSeed));
add(LIST32, new Well44497a(intSeed));
add(LIST32, new Well44497b(intSeed));
add(LIST32, new ISAACRandom(intSeed));
add(LIST32, new MultiplyWithCarr
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640723#comment-16640723
]
Gilles commented on RNG-57:
---
bq. I am wondering if the ProvidersList should make a better attempt at
creating a full length seed.
As you note, the "scramble" method is supposed to avoid obvious pitfalls like
the seed being mostly zeroes or other periodic set of bits.
If only full length seeds were necessary to make tests that use a few generated
numbers pass, I'd guess that it would indicate an expectation problem (thus
change the test) or a dysfunctional RNG (thus fix the RNG).
My preference would be to have the unit test run with different (random) seeds
at each build. Junit can take care of repeating failing tests (called "flaky")
but IIUC, it would only rerun a {{@test}} whereas in this case, it is the
{{ProvidersList}} instance that must be reloaded. So this would imply moving
the code from a {{static}} block to a regular constructor, and pass it to the
unit test classes in a different way.
Currently, I don't think this refactoring is worth the time and the possible
drawbacks.
bq. I can create a temp branch to try different seeds until it passes on Travis
then formulate an atomic PR.
Agreed; the first thing would be to "empirically" try a few seeds to ensure
that the tests pass much more often than they fail.
If that's the case; the stress tests suites will ensure (if the result are OK)
that the cache did not degrade the quality of the randomness of {{nextInt()}}.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640855#comment-16640855
]
Alex D Herbert commented on RNG-57:
---
I've had a look at {{ProvidersCommonParametricTest}} and why this fails.
In summary the test runs the RNG to create a uniform sample using 1000 samples
and tests it is uniform using a Chi squared test with a critical value at 1%.
500 repeat chi square tests are made and if more than 2% fail then this is a
test fail.
This is fair.
I only found one bug in the test and that was a rounding error setting the
range of the upper bin when the max was 2305843009213693951L (Long.MAX_VALUE /
4). It was out by 1 and so not a problem with a range this big and not the
reason for the test being flaky.
I did notice that the test is usually failing when the range under test is an
integer range that is not a power of 2. So it may be failing because the test
is checking not the randomness of the entire binary bits from the RNG but the
algorithm for generating an integer that is not a power of two. This algorithm
does not use the entire binary bits but is biased to using the least
significant bits since it sets the returned value using the modulus of the
binary bits using a rejection algorithm:
{code:java}
// Excerpt from BaseProvider.nextInt(int)
do {
bits = nextInt() >>> 1;
// Here the bits returned are composed of the least
// significant bits (bar one) from the random
val = bits % n;
} while (bits - val + (n - 1) < 0);
{code}
Since I have modified {{ProvidersCommonParametricTest}} to randomly seed each
time I am running it 1000 times and logging the number of test fails for each
test, e.g.
{noformat}
org.apache.commons.rng.core.source32.Well512a: Pass for n = 1234 (9
out of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 4 (0 out
of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 10 (6 out
of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 12 (8 out
of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 31 (3 out
of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 32 (4 out
of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 2016128993
(2 out of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 1834691456
(7 out of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 869657561
(7 out of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 1570504788
(9 out of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 4 (0 out of
500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 11 (6 out of
500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 19 (5 out of
500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 31 (8 out of
500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 32 (4 out of
500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 2305843009213693951
(4 out of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 4611686018427387902
(9 out of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 6917529027641081853
(2 out of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 578 (3
out of 500 tests failed)
{noformat}
We expect to see 5 out of 500 tests failed.
I am going to do some analysis on the output to see if the tests for non-power
of two {{nextInt(int)}} and {{nextLong(long)}} are more flaky than the others.
If correct then this may be solved by:
- increasing the tolerance for those tests (i.e. >2% fail rate)
- increasing the number of samples for those tests (i.e. >1000)
- removing those tests and just using nextBytes[]
The last idea or a modification of it is to just test the RNG produces an
acceptable random stream of bits. Although fine for the current providers it
would not cover future providers that may override nextFloat, nextDouble,
nextInt(int), nextLong(long).
> 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}}
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640891#comment-16640891
]
Alex D Herbert commented on RNG-57:
---
Having though about this the simulation can be modelled as a Binomial
distribution.
Each Chi square test has a probability of failure of 0.01 (if the RNG is
perfect).
Here's the CDF for a Binomial(n=500, p=0.01):
||Number of failures (k)||CDF(x <= k)||1 - CDF(x <= k)||
|0|0.0066|0.9934|
|1|0.0398|0.9602|
|2|0.1234|0.8766|
|3|0.2636|0.7364|
|4|0.4396|0.5604|
|5|0.6160|0.3840|
|6|0.7629|0.2371|
|7|0.8677|0.1323|
|8|0.9329|0.0671|
|9|0.9689|0.0311|
|10|0.9868|0.0132|
|11|0.9948|0.0052|
|12|0.9981|0.0019|
|13|0.9994|0.0006|
|14|0.9998|0.0002|
|15|0.|0.0001|
|16|1.|0.|
So the current limit of 10 will be exceeded at a rate of (1 - 0.9868) = 0.0132.
To make the test robust the p-value for failure can be set at p=0.001. Then the
limit would have to be 13 failures.
If the RNG is not perfect then the Chi square test will fail more often than 1%
of the time and this should easily be detected.
I'll collate the results from testing each provider with random seeds and see
what the failure rate would be for each at different failure thresholds.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641535#comment-16641535
]
Gilles commented on RNG-57:
---
bq. what the failure rate would be for each
Why should the number of expected failures be different for each algorithm?
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641616#comment-16641616
]
Alex D Herbert commented on RNG-57:
---
bq. Why should the number of expected failures be different for each algorithm?
Because they are not all perfect. The DieHarder results show that.
The null hypothesis is that the RNG is perfect and the binomial distribution
can be used to determine how many failures to expect for the repeated Chi
square test.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641739#comment-16641739
]
Gilles commented on RNG-57:
---
{quote}Because they are not all perfect.
{quote}
I was expecting the answer.
{quote}The DieHarder results show that.
{quote}
Indeed. And it is unlikely that the unit tests of "Commons RNG" can do better
than the "Big Crush" test suite. Thus I don't think that we should evaluate the
quality of the underlying source: the unit test should identify a bug in the
Java implementation, not a flawed RNG algorithm.
If the issue here is not a seed problem, we can make the build more robust by
setting the JUnit config to repeat "flaky" tests. If some RNG sources fail
more often than others, it is already a piece of information, while being more
tolerant for bad generators is not a good idea IMO.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641910#comment-16641910
]
Alex D Herbert commented on RNG-57:
---
Apologies in advance for the long post. This stems from the desire to
understand why my simple changes for RNG-57 have broken the test suite for
commons-rng-core.
I ran the {{ProvidersCommonParametricTest}} test 1000 times with a random seed
generated by SecureRandom as a 1024 byte array. Code snippet to do this is
posted in [#comment-16640722].
The raw data were large (>40MB) so I extracted the number of failures for each
test and have uploaded this to my current PC. Unfortunately I produced the raw
data incorrectly as the test stops at the first failure and later tests will be
missing repeats. So for example this test for nextInteger has incomplete data
because early tests fail:
{code:java}
@Test
public void testUniformNextIntegerInRange() {
checkNextIntegerInRange(4, 1000);
checkNextIntegerInRange(10, 1000);
checkNextIntegerInRange(12, 1000);
// If this fails ...
checkNextIntegerInRange(31, 1000);
// Data for the remaining will be missing !!!
checkNextIntegerInRange(32, 1000);
checkNextIntegerInRange(2016128993, 1000);
checkNextIntegerInRange(1834691456, 1000);
checkNextIntegerInRange(869657561, 1000);
checkNextIntegerInRange(1570504788, 1000);
}
{code}
However the number of tests is always above 900 and so I did a Chi squared test
to determine if the number of failures fits a Binomial distribution. Here are
some demo results for the MWC_256 method.
The table shows the method under test, the mean number of failures, the p-value
from a chi squared test matching the histogram of failures to a Binomial and
then a cumulative histogram of the number of failures. The final column value
is the number of tests (sometimes less than 1000).
|Method|Mean fails|p(Binomial(n,p=0.01)|Cumul Fails
(X<=x\|x=0)|1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|
|nextInteger(1834691456)|5.027|0.999|6|49|130|256|406|565|710|812|892|923|937|947|950|950|951|
|
|nextLong(6917529027641081853)|4.904|1|9|41|127|252|418|580|719|828|867|898|920|926|928|
| | |
|nextDouble()|4.928|0.989|8|42|131|265|446|633|772|876|940|973|989|998|999|1000|
| |
|nextInteger(32)|4.889|0.997|6|38|130|268|451|619|761|848|909|941|958|964|967|969|
| |
|nextInteger(10)|4.914|0.991|9|36|121|270|460|636|776|872|940|976|994|997|999|1000|
| |
|nextInteger(1570504788)|4.902|1|4|38|118|256|429|594|725|809|867|899|918|921|923|925|925|926|
|nextInteger(2016128993)|4.98|1|6|39|110|230|428|585|749|839|900|935|951|954|957|958|
| |
|nextInteger(31)|4.969|0.996|9|40|132|265|450|606|753|839|901|952|969|975|979|980|
| |
|nextLong(31)|4.99|0.999|7|32|106|253|429|601|747|845|911|947|964|968|969|970|971|
|
|nextLong(4611686018427387902)|4.989|1|7|44|122|254|404|572|721|819|876|912|928|940|940|940|941|
|
|nextLong(32)|5.053|1|7|36|113|240|408|585|728|845|897|929|949|961|963|964| | |
|nextInteger(12)|5.016|0.994|6|44|129|261|436|610|752|856|925|961|980|985|992|993|994|
|
|nextFloat()|4.953|0.991|8|42|129|261|428|625|777|878|949|974|984|994|998|1000|
| |
|nextLong(11)|4.922|0.991|7|36|135|272|440|631|776|890|940|973|986|995|997|1000|
| |
|nextLong(2305843009213693951)|5.046|1|1|33|109|241|401|582|704|826|894|924|941|945|947|949|
| |
|nextInteger(4)|0|0|1000| | | | | | | | | | | | | | | |
|nextLong(4)|0|0|1000| | | | | | | | | | | | | | | |
|nextLong(19)|4.977|0.997|5|37|130|271|448|620|744|855|915|948|971|983|984|986|
| |
|nextInteger(869657561)|4.918|1|5|33|98|252|409|599|749|831|886|915|926|934|936|937|
| |
Here are some conclusions:
- Repeating the Chi squared test for uniformity 500 times with a critical
p-value of 0.01 produces counts that can be modelled as a binomial distribution.
- The mean is 5 (n*p = 500*0.01).
- The test for nextInteger/Long(4) always passes. The test is performed using
10 bins and there only 4 discrete values. Basically the test is invalid and the
Chi square test should be done using 3 degrees of freedom.
- The test fail threshold of 10 allowed failures corresponds to a cumulative
probability of 0.9868 (see [#comment-16640891]). This means it will fail 1.32%
of the time.
Note that currently there are 19 tests using this approach. We can discount 2
(nextInteger(4) and nextLong(4)) leaving 17. There are also 3 random walk tests
with a 1% critical value on the range allowed and 2 tests for uniform next
bytes using a single chi squared p-value of 1%.
So for a single RNG the probability that no tests will fail is:
{noformat}
(1 - 0.0132)^17 * (1 - 0.01)^3 * (1 - 0.01)^2 = 0.7587
{noformat}
The test is performed on 16 variants of the RNG. So the probability no tests
will fail is:
{noformat}
0.7587^16 = 0.0121
{noformat}
This seems very low. I don't have data for the random walk
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642648#comment-16642648
]
Gilles commented on RNG-57:
---
bq. Apologies in advance for the long post.
A very interesting analysis (and a useful appendix to the user guide perhaps).
Here on JIRA, it's not easy to follow the discussion (e.g. wide tables are not
displayed in their entirety).
Codes (that would produce the above tables) could go in the
{{commons-rng-examples}} module.
bq. An alternative approach would be to reduce the number of tests per RNG.
These could be limited to nextBytes and either nextInt or nextLong depending on
the type of provider.
Did I understand correctly that you propose to
# test the randomness uniformity of each of the implementations of
{{IntProvider}} (resp. {{LongProvider}}) through exercising {{nextInt()}}
(resp. {{nextLong()}}) only, and
# test the rest of the methods defined in {{UniformRandomProvider}} using
{{SecureRandom}} as the source?
bq. It is not very convenient for local development though as builds will fail
a fair amount.
JUnit is set to rerun failing tests (once in the current config); it seems to
work fine for module {{commons-rng-sampling}}, where the distribution tests do
indeed use random seeds.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643062#comment-16643062
]
Alex D Herbert commented on RNG-57:
---
bq. Did I understand correctly that you propose to
Yes.
The test suite should satisfy the aims:
1. Demonstrate each implementation is a valid Java port (if it is a port)
2. Demonstrate each implementation is an 'acceptable' source of randomness for
int/long
3. Demonstrate each implementation can be saved and restored, no matter what
the initial seed and current state
4. Demonstrate a source of randomness for int/long can be used to produce
randomness for boolean, float, double and a range of int/long (i.e. the
UniformRandomProvider interface)
5. Exercise all the code paths and expected edge case behaviour
6. Leave thorough statistical analysis of the randomness of each provider to
the Big Crush test
IMO the current test suite does this except for using random seeds to create
the providers. However it over tests certain parts of the code due to
repetition and due to the nature of the the tests this results in a high
overall failure rate for the entire test suite.
Currently each provider has a unit test that demonstrates the Java port of the
algorithm is functioning as per the original source.
Then each algorithm is used to provide either {{int}} or {{long}} as the base
of all randomness.
So unit test the base implementation of UniformRandomProvider for int/long
once. This should be done using a very random source such as the strongest
cryptographically secure algorithm in SecureRandom.
Then unit test the construction edge cases and save/restore functionality of
each provider. This can use random seeds to ensure a robust test suite. These
tests should never fail.
Then finally test the nextInt() and nextLong() methods of each provider only
once. This can be created to have a known fail rate that is acceptable. E.g.
use a single Chi squared test with a known fail rate, e.g. 1%. Or do repeated
Chi squared test on small samples and then test the results follow a Binomial
distribution with a p of 0.01. For simplicity a single Chi squared test of a
long run of the provider sequence would be my choice.
The test for nextInt or nextLong can either compress all the bits into bytes
for a 256 bin histogram for the Chi square test or use a 1024 bin histogram for
int (4 * 256 bins with each set coming from a 8-bit block of the integer) and
2048 bins for long.
Currently the tests for nextInt/Long/Float/Double use 1000 samples repeated 500
times in 19 individual test runs. That is 9,500,000 samples. This could be
compressed into a single test. If this was set to 1,024,000 samples a uniform
distribution over 2048 bins would have 500 samples per bin. This would run 9
times faster than the current test suite and should fail at a known rate, e.g.
1%. Allowing each test to be repeated 1 time by JUnit in event of failure will
then cause the fail rate to drop to (0.01)^2, or 0.01% of the time.
With 16 providers the likelihood of a failure of all providers is low and the
likelihood of a pass of all 16 is:
{noformat}
(1 - 0.0001)^16 = 0.998
{noformat}
So if failed tests can be repeated just once you will see Travis jobs failing
0.2% of the time. This assumes each RNG provider is perfect and will fail
exactly 1% of the time.
I'd then suggest some data collation of failures be performed over a long
period. Each RNG should fail 1% of the time but this can be examined when the
suite has been run a few thousand times by Travis. Such data can be collated
periodically and could form a page for the user guide.
> 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
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643160#comment-16643160
]
Gilles commented on RNG-57:
---
bq. The test suite should satisfy the aims
I'm fine with further consolidating the unit test suite.
Would you write it out in a new section of the [user
guide|https://git1-us-west.apache.org/repos/asf?p=commons-rng.git;a=blob;f=src/site/apt/userguide/rng.apt;h=8ae6f92910dc99c921ee84809ebe6ae3b7357116;hb=HEAD]
(as section "5. Unit testing", moving the current "5. Quality" to "6. External
testing")?
bq. tests for nextInt/Long/Float/Double \[...\] could be compressed into a
single test.
How would a single test detect which of the {{NumberFactory}} methods were
buggy?
bq. can be examined when the suite has been run a few thousand times by Travis.
Why not run locally?
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16643229#comment-16643229
]
Alex D Herbert commented on RNG-57:
---
bq. How would a single test detect which of the NumberFactory methods were
buggy?
The {{NumberFactory}} is used in the base implementation of
{{UniformRandomProvider}} by {{IntProvider}} or {{LongProvider}}. I suggested
that is tested once for all methods using e.g. SecureRandom as the source. No
need to test this for each provider.
It is also used in the save/restore state functions by each provider and that
will still be tested for each provider.
bq. Why not run locally?
No reason. Good catch.
I was thinking that it would be nice to collate results over a large number of
tests. However it would be better to do it once with a snapshot of the code.
Using results from Travis for each build will end up polluting the results over
time if code changes are made to the core providers.
My test for 1000 repeats of the test suite took about 4 hours on my laptop. So
it is easy to run overnight and get some reasonable statistics.
bq. Would you write it out in a new section of the user guide
OK. Sounds like tickets for the following:
- Improvement: Add details of RNG testing to the user guide. This outlines the
the aim of the test suite and provides a table of results for the number of
times each RNG provider fails. This can be run locally before a release, or
when the core module is updated.
- Improvement: Refactor the tests for the core module to allow use of random
seeds. Improve robustness of the tests using targeted testing of the random
sequence of each provider allowing the test to fail under given statistical
assumptions.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688792#comment-16688792
]
Alex D Herbert commented on RNG-57:
---
A post to the commons developers list mentioned a release for v1.2 with this as
the last outstanding issue. I am not sure my reply to the mailing list is
published so I repeat is here:
===
The speed improvement has been demonstrated. However the effect on the
randomness has not been tested using the 3rd party DieHarder and BigCrush test
suites. I would be reluctant to change the core library without verifying the
impact of the change.
A second issue is that the change causes the current test suite to fail. As
explained in this thread this is due to the high number of tests with a 1%
acceptance level. Basically after enough tests for randomness something will
almost certainly fail. The current test suite is expected to (and does) fail
over 98% of the time with random seeds. It currently uses fixed seeds that work.
Ideally the suite would work with random seeds and use a more selective set of
tests (to reduce the chance for failures) but I have not had time to look at
reengineering the test suite.
It may be better to delay this for a later release.
===
Is there a guide for how to run DieHarder and BigCrush? I can do that with the
changes and post the results. That should at least verify that the speed
improvement has not broken the {{nextInt}} functionality of the
{{LongProvider}}.
If the change is OK then work should be done to make the test suite more robust
as outlined in comment [#16643062], e.g.:
- Change to test each provider only once for the {{int}} or {{long}} source of
randomness
- Change to test the underlying implementation of the
{{UniformRandomProvider}} interface once for the {{int}} or {{long}} random
source
Once complete then this change can be put into a PR.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688914#comment-16688914
]
Gilles commented on RNG-57:
---
bq. Is there a guide for how to run DieHarder
There is a {{RandomStressTester}} Java application class under directory
{{commons-rng-examples/examples-stress}}.
It can start the "dieharder" program (to be installed separately). See the
comments in the Java file.
bq. and BigCrush?
There is a little "bridge", in C, under
{{commons-rng-examples/examples-stress/src/main/c}}.
After compiling it (after having installed "TestU01" separately), it can be run
through the above Java application.
bq. make the test suite more robust
I've created RNG-60 as step in that direction (and perhaps it will be "good
enough").
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689433#comment-16689433
]
Alex D Herbert commented on RNG-57:
---
Using RNG-60 I have made the same changes that previously failed and they now
pass.
Do you want a PR to see the changes?
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689499#comment-16689499
]
Alex D Herbert commented on RNG-57:
---
BigCrush
I manged to get this to work using:
{code:java}
> sudo aptitude install libtestu01 libtestu01-dev testu01-bin
> cd commons-rng-examples/examples-stress
> gcc src/main/c/stdin2testu01.c -ltestu01 -ltestu01mylib -ltestu01probdist -o
> stdin2testu01
{code}
DieHarder
{code:java}
> sudo aptitude install dieharder
{code}
RandomStressTester
I modified examples-stress/pom.xml to use the maven shade plugin to build the
examples.jar.
These changes could be put into a PR so they make running the tests easier.
I can now run DieHarder and BigCrush. How long should they take? Is this an
overnight job?
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689506#comment-16689506
]
Gilles commented on RNG-57:
---
bq. Do you want a PR to see the changes?
Yes!
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689530#comment-16689530
]
Gilles commented on RNG-57:
---
bq. PR so they make running the \[stress\] tests easier.
Yes, please.
Could the "shade" plugin config be shared for making it easy to run all the
examples that contain a {{main}} method (see RNG-29)?
bq. I can now run DieHarder and BigCrush. How long should they take? Is this an
overnight job?
Durations are output at the end of the run; see the output files in the [user
guide|http://commons.apache.org/proper/commons-rng/userguide/rng.html#a5._Quality].
Depending on the RNG under test,
* a "Dieharder" run takes from about 100 to 250 minutes,
* a "BigCrush" run takes from about 500 to 2000 minutes,
per RNG.
I'd guess that's the reason there are 3 suites in TestU01...
Do you have a big cluster? :)
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689582#comment-16689582
]
Alex D Herbert commented on RNG-57:
---
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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689734#comment-16689734
]
ASF GitHub Bot commented on RNG-57:
---
GitHub user aherbert opened a pull request:
https://github.com/apache/commons-rng/pull/12
RNG-57: Cache values for provision of nextBoolean and nextInt
This PR contains the suggested changes to implement a cache to speed up the
`nextInt` and `nextBoolean` methods in the core provider implementations.
These changes improve performance but the effect on the `nextInt` method of
`LongProvider` is unknown. A repeat of the DieHarder and TestU01 test suites is
currently in progress.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/aherbert/commons-rng improvement-RNG-57
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-rng/pull/12.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #12
commit 91a5eec2d8a3318cf8fc8e6d222ac3edf3a0d969
Author: aherbert
Date: 2018-11-16T13:10:51Z
RNG-57: Cache values for provision of nextBoolean and nextInt
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689751#comment-16689751
]
ASF GitHub Bot commented on RNG-57:
---
Github user coveralls commented on the issue:
https://github.com/apache/commons-rng/pull/12
[](https://coveralls.io/builds/20148825)
Coverage decreased (-0.2%) to 97.358% when pulling
**91a5eec2d8a3318cf8fc8e6d222ac3edf3a0d969 on aherbert:improvement-RNG-57**
into **0fdcd9007c708aa48f1989cb2211ea56c1fcd702 on apache:master**.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16691772#comment-16691772
]
Alex D Herbert commented on RNG-57:
---
I have the results of DieHarder and BigCrush for the {{LongProvider}} RNGs.
Parsing DieHarder is easy. Just count FAILED except for the diehard_sums test.
Parsing BigCrush I just count the number of failed tests in the summary at the
end.
I have found discrepancies in the [user
guide|https://commons.apache.org/proper/commons-rng/userguide/rng.html] table
for the current results. Here is what I find:
||RNG identifier||Dieharder||TestU01 (BigCrush)||
|JDK|14 16 15|78 75 76|
|MT|0 0 0|2 2 2|
|WELL_512_A|0 0 0|6 6 6|
|WELL_1024_A|0 0 0|4 4 5|
|WELL_19937_A|0 0 0|2 3 4|
|WELL_19937_C|0 0 0|2 2 2|
|WELL_44497_A|0 0 0|3 3 2|
|WELL_44497_B|0 0 0|2 2 3|
|ISAAC|0 0 0|1 0 0|
|MT_64|0 0 0|2 2 3|
|SPLIT_MIX_64|0 0 0|0 0 0|
|XOR_SHIFT_1024_S|0 0 0|0 0 0|
|TWO_CMRES|0 1 0|0 0 0|
|MWC_256|0 0 0|0 0 0|
|KISS|0 0 0|0 1 0|
* WELL_1024_A is wrong for BigCrush (the user guide states 4,6,5)
* WELL_1024_A and WELL_44497B are wrong for Dieharder as the diehard_sums test
failure is not ignored
Here are the results from the modified {{LongProvider}} RNGs:
||RNG identifier||Dieharder||new||TestU01 (BigCrush)||new||
|MT_64|0 0 0|0 0 0|2 2 3|3 4 3|
|SPLIT_MIX_64|0 0 0|0 0 0|0 0 0|0 1 0|
|XOR_SHIFT_1024_S|0 0 0|0 0 0|0 0 0|0 0 0|
|TWO_CMRES|0 0 0|1 1 1|0 0 0|0 0 1|
So the change has made the RNGs slightly worse with the exception of
XOR_SHIFT_1024_S, which still has no failures.
Here's a breakdown of the failed tests:
||RNG identifier||Test||Old||New||
|MT_64|BigCrush LinearComp, r = 0|3|3|
|MT_64|BigCrush LinearComp, r = 29|3|3|
|MT_64|BigCrush HammingIndep, L=300, r=0|1|0|
|MT_64|BigCrush CollisionOver, t = 14|0|1|
|MT_64|BigCrush SampleProd, t = 16|0|1|
|MT_64|BigCrush RandomWalk1 H (L=1, r=15)|0|1|
|MT_64|BigCrush RandomWalk1 J (L=1000, r=0)|0|1|
|SPLIT_MIX_64|BigCrush ClosePairs mNP2, t = 9|0|1|
|TWO_CMRES|diehard_dna|0|3|
|TWO_CMRES|BigCrush RandomWalk1 C (L=50, r=25)|0|1|
* MT_64 is still bad at the LinearComp test. This tests complexity of each
successive bit from the bit sequence. It also fails the CollisionOver test
which tests the uniformity of overlapping tuples from the sequence. So the
MT_64 sequence is not random when compared to parts of itself. It also fails
the SampleProd test that uses the entire bit sequence. Perhaps this RNG should
be avoided. Note however that the new failures are just outside the allowed
p-values. The LinearComp test fails with p < 1e-15 compared to the allowed
0.001.
* SPLIT_MIX_64 fails a test using the entire bit sequence. The failure is
p=0.9996 which is just outside p=0.9990. This is marginal fail.
* TWO_CMRES is now bad at the diehard_dna test. This is marked as suspect in
the version I installed (3.31.1) and perhaps these should be ignored.
Failures on the RandomWalk tests (MT_64, TWO_CMRES) of BigCrush are
interesting. According to the user guide (p.120)
[http://simul.iro.umontreal.ca/testu01/guideshorttestu01.pdf]
the walk of _{{L}}_ steps is performed using _{{s}}_ bits from each random
{{int}} after dropping _{{r}}_ bits. So the {{RandomWalk r=0}} test is actually
testing the new implementation of {{nextBoolean}} which obtains booleans using
all the bits from a random sample. The results show a few failures in this test
with the new implementation. The test is more rigorous than the random walk
test in the core module as it tests the number of sign changes during the walk
from zero and the time spent on each side. A failure of this test shows that
the cached {{nextBoolean}} is not robust.
Note that the failures are marginal:
{noformat}
79 RandomWalk1 H (L=1, r=15) 6.9e-4
76 RandomWalk1 J (L=1000, r=0) 4.1e-4
75 RandomWalk1 C (L=50, r=25) 7.5e-4
{noformat}
Mean run times (in minutes):
Old:
||RNG identifier||Dieharder||TestU01 (BigCrush)||
|JDK|268.68 +/- 24.12|1918.44 +/- 10.08|
|MT|189.15 +/- 3.26|1837.33 +/- 20.28|
|WELL_512_A|195.51 +/- 6.70|1827.63 +/- 5.55|
|WELL_1024_A|101.55 +/- 4.76|1864.89 +/- 24.80|
|WELL_19937_A|108.35 +/- 6.14|1914.86 +/- 14.91|
|WELL_19937_C|122.08 +/- 7.79|1922.84 +/- 8.42|
|WELL_44497_A|111.41 +/- 3.44|1923.36 +/- 10.69|
|WELL_44497_B|112.22 +/- 2.57|1926.86 +/- 33.81|
|ISAAC|105.32 +/- 0.85|1837.63 +/- 10.47|
|MT_64|101.64 +/- 2.94|1819.06 +/- 19.88|
|SPLIT_MIX_64|96.12 +/- 4.80|480.92 +/- 19.77|
|XOR_SHIFT_1024_S|99.05 +/- 3.46|508.50 +/- 5.06|
|TWO_CMRES|105.38 +/- 4.22|502.01 +/- 9.68|
|MWC_256|105.99 +/- 13.19|490.15 +/- 4.02|
|KISS|75.80 +/- 3.61|487.72 +/- 7.65|
New:
||RNG identifier||Dieharder||TestU01 (BigCrush)||
|MT_64|102.30 +/- 2.27|1355.75 +/- 10.52|
|SPLIT_MIX_64|101.80 +/- 1.56|1336.16 +/- 12.60|
|XOR_SHIFT_1024_S|107.09 +/- 5.47|1344.89 +/- 12.96|
|TWO_CMRES|108.57 +/- 6.24|1341.70 +/- 13.50|
The BigCrush algorithm was run on an old 1
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16693722#comment-16693722
]
Gilles commented on RNG-57:
---
bq. WELL_1024_A is wrong for BigCrush (the user guide states 4,6,5)
Typo indeed.
bq. WELL_1024_A and WELL_44497B are wrong for Dieharder as the diehard_sums
test failure is not ignored
The table shows all failures, to be consistent with the output from the
software; the note indicates that "diehard_sums" may not be trusted (as per the
note on the software's web site), not that it is not counted.
bq. The changes to use cached values slightly increase the number of failures
How do you draw that conclusion?
I'd think that some of the results are different because the seed/sequences are
different.
I'll commit the new result files (for all RNGs).
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16693792#comment-16693792
]
ASF GitHub Bot commented on RNG-57:
---
Github user asfgit closed the pull request at:
https://github.com/apache/commons-rng/pull/12
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16693829#comment-16693829
]
Gilles commented on RNG-57:
---
bq. I'll commit the new result files
Done.
We should also update the benchmarks.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694594#comment-16694594
]
Alex D Herbert commented on RNG-57:
---
{quote}How do you draw that conclusion?
{quote}
Because the number of failures seen across the {{LongProviders}} went up.
However the change is not dramatic and most could be attributed to different
random seeds. As I pointed out a few of the tests are marginal fails on
BigCrush. I think the change has definitely made TWO_CMRES fail the
dieharder_dna test.
I realised that rerunning the tests for the {{IntProviders}} is not needed
other than to get more results. The implementation tested ({{nextInt}}) has not
changed. So in the interest of completeness I am running the tests 3 more times
for the {{LongProviders}}. That will provide 6 sets of results for DieHarder
and BigCrush for all providers. 6 new sets for the {{LongProviders}} and 3 new
sets to complement the existing 3 sets for {{IntProviders}}.
The results should be finished tomorrow. How do you want to receive the raw
text files? I can put them into the src/site directory in rng-parent. I can
overwrite the old {{LongProvider}} results or add new folders.
{quote}the note indicates that "diehard_sums" may not be trusted (as per the
note on the software's web site), not that it is not counted.
{quote}
I think that this may mislead a browser of the user guide that some of the RNGs
are worse when actually they fail a test that should not be used. Here's what
the software says about it:
{noformat}
> dieharder -d 14 -h
# Comments
#
# At this point I think there is rock solid evidence that this test
# is completely useless in every sense of the word. It is broken,
# and it is so broken that there is no point in trying to fix it.
# The problem is that the transformation above is not linear, and
# doesn't work. Don't use it.
#
# For what it is worth, rgb_lagged_sums with ntuple 0 tests for
# exactly the same thing, but scalably and reliably without the
# complication of overlapping samples and covariance. Use it
# instead.
{noformat}
The fact that it is stated that the test should not be used justifies removing
it from the results table. If it is not removed then a flag to indicate that
WELL_1024_A and WELL_44497_B failed 1 test but it was dieharder_sums would be
useful.
I do not think that many will actually click through and digest the results in
full. If they do then a note that the dieharder_sums test is ignored in the
main table should be known to that type of user.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694613#comment-16694613
]
Alex D Herbert commented on RNG-57:
---
{quote}I'll commit the new result files
{quote}
Done.
I see that you have already re-run all the results and updated {{master}}. Do
you still want my re-run?
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694646#comment-16694646
]
Gilles commented on RNG-57:
---
{quote}I think that this may mislead a browser of the user guide that some of
the RNGs are worse
{quote}
This would only result from not reading the docs correctly.
I admit that we can/could put more info but if the premise is that it won't be
read thoroughly... ;)
The initial idea (of including the output of external tools) was to show that
users should not blindly use the JDK's {{Random}} class (and that's pretty
clear from the userguide).
Going beyond that is fine on the condition that we provide a robust script that
will start "DieHarder" and "[Big]Crush", then parse their outputs and generate
the table(s) to be readily included in the docs. Personally, I don't think it's
worth the time: It's the second time I run them (not counting the "trials and
errors" pre-initial release). Will you do it?
By the same token, I'd not add more data to the table; 3 runs is fine to show
that results do vary.
Again, unless there is a script and you want to run the suites many more times
in order to be able to make histograms...
bq. I think the change has definitely made TWO_CMRES fail the dieharder_dna
test.
What can we conclude from that?
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694670#comment-16694670
]
Alex D Herbert commented on RNG-57:
---
{quote}we provide a robust script that will start "DieHarder" and "[Big]Crush"
{quote}
I already had to write a script to parse the output and generate a table for
this ticket. Surely you also have scripts that you are using to create the user
guide?
I was going to submit the changes I made to {{examples-stress}} to build the
shaded jar file as a PR. I could add my scripts. However they are far from
robust. If this is a desired output, e.g. for RNG-29, then some more work
should be done to make the executable jar files with a {{main}} a bit more user
friendly, e.g. a decent help message.
{quote}What can we conclude from that?
{quote}
Not much. The dieharder_dna test is marked as suspect anyway. Literally it
would mean do not use that RNG to generate 4 letter DNA sequences using
consecutive 2-bit letters from the {{int}}. This does have implications for the
{{StringSampler}} discussed in RNG-54 since that is exactly what was discussed
(for any power of 2 alphabet).
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694802#comment-16694802
]
Gilles commented on RNG-57:
---
{quote}Surely you also have scripts
{quote}
Yes, but it's all semi-manual: generating a JAR with all dependencies (from a
different POM), a script to start the runs, another to print out the number of
failures, copying/pasting each of them to the userguide. Tedious and not robust
(typos and all).
{quote}for RNG-29, then some more work should be done
{quote}
Indeed.
But the question is whether either you or I want to devote a lot of CPU time
to a massive run (see a [report|http://xoshiro.di.unimi.it/#shootout] from 100
runs).
Time might be better spent porting other RNGs (e.g. newer algorithms provided
at the above site).
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694881#comment-16694881
]
Alex D Herbert commented on RNG-57:
---
{quote}generating a JAR with all dependencies (from a different POM){quote}
Using the shade plugin to generate the jar with all the dependencies is easy.
I'll do a PR for that. I can put in my scripts to parse the output. You can
always remove them.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694903#comment-16694903
]
Gilles commented on RNG-57:
---
bq. shade plugin \[...\] PR
Thanks.
bq. I can put in my scripts
Better different PR for different things.
Scripts can be attached to a new JIRA issue, perhaps as a starting point
towards something more "integrated" (auto-generated reports).
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695468#comment-16695468
]
Gilles commented on RNG-57:
---
I'm worried by the {{nextBoolean}} benchmark result:
{noformat}
*--*+
|| RNG identifier || Score ratio |
*--*+
| MWC_256 |0.89062 |
*--*+
| MT |0.90006 |
*--*+
| KISS |0.90939 |
*--*+
| WELL_44497_B |0.93249 |
*--*+
| WELL_19937_A |0.93395 |
*--*+
| WELL_44497_A |0.93663 |
*--*+
| ISAAC|0.94705 |
*--*+
| WELL_512_A |0.94886 |
*--*+
| WELL_19937_C |0.95391 |
*--*+
| WELL_1024_A |0.96226 |
*--*+
| JDK |1.0 |
*--*+
| SPLIT_MIX_64 |1.04807 |
*--*+
| TWO_CMRES|1.05701 |
*--*+
| MT_64|1.08643 |
*--*+
| XOR_SHIFT_1024_S |1.08982 |
*--*+
{noformat}
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695893#comment-16695893
]
Alex D Herbert commented on RNG-57:
---
{quote}I'm not sure: What ensures that the previous implementation to retrieve
a boolean from the underlying RNG is better?
{quote}
I'd not considered this. The only way to know would be to test it. This could
be done by targeting the specific tests for RandomWalk within BigCrush using
only the first bit (i.e. dropping all the other bits). This is possible using
the C library API. Or build a RNG that composes an {{int}} using 32 calls to
the underlying source using the upper bit from each source. This could be
tested using the existing framework with all the test suites.
It is simpler to just advise against using poor RNGs and stick to those with
low errors from BigCrush.
For systematic errors I have ignored dieharder_sums. I store a failure in each
occurrence of the same test. For BigCrush the test has a test Id. This is the
same even though the test may have multiple parts, e.g. this is one test
failure:
{noformat}
74 RandomWalk1 H (L=50, r=0)eps
74 RandomWalk1 M (L=50, r=0)eps
74 RandomWalk1 J (L=50, r=0)eps
74 RandomWalk1 R (L=50, r=0)eps
74 RandomWalk1 C (L=50, r=0)eps
{noformat}
For Dieharder the test has a name then a parameter (ntup), e.g. this is two
tests:
{noformat}
rgb_lagged_sum| 14| 100| 100|0.95188466| PASSED
rgb_lagged_sum| 15| 100| 100|0.| FAILED
{noformat}
Here's the old systematic failures table using the original txt results files
for the {{LongProviders}}:
||RNG identifier||Test suite||Systematic failures||Fails||
|MT_64|TestU01 (BigCrush)|80:LinearComp|3/3|
|MT_64|TestU01 (BigCrush)|81:LinearComp|3/3|
Here's the new systematic failures table:
||RNG identifier||Test suite||Systematic failures||Fails||
|MT_64|TestU01 (BigCrush)|80:LinearComp|9/9|
|MT_64|TestU01 (BigCrush)|81:LinearComp|9/9|
|TWO_CMRES|Dieharder|diehard_dna:0|9/9|
So as stated previously the TWO_CMRES is now failing a Dieharder test that is
marked as suspect. No other RNGs have changed to systematic failure.
FYI for the {{IntProviders}}:
||RNG identifier||Test suite||Systematic failures||Fails||
|JDK|Dieharder|diehard_oqso:0|9/9|
|JDK|Dieharder|diehard_dna:0|9/9|
|JDK|Dieharder|rgb_minimum_distance:3|9/9|
|JDK|Dieharder|rgb_minimum_distance:4|9/9|
|JDK|Dieharder|rgb_minimum_distance:5|9/9|
|JDK|Dieharder|rgb_lagged_sum:15|9/9|
|JDK|Dieharder|rgb_lagged_sum:31|9/9|
|JDK|Dieharder|dab_bytedistrib:0|9/9|
|JDK|Dieharder|dab_filltree:32|9/9|
|JDK|TestU01 (BigCrush)|1:SerialOver|9/9|
|JDK|TestU01 (BigCrush)|3:CollisionOver|9/9|
|JDK|TestU01 (BigCrush)|5:CollisionOver|9/9|
|JDK|TestU01 (BigCrush)|7:CollisionOver|9/9|
|JDK|TestU01 (BigCrush)|9:CollisionOver|9/9|
|JDK|TestU01 (BigCrush)|11:CollisionOver|9/9|
|JDK|TestU01 (BigCrush)|13:BirthdaySpacings|9/9|
|JDK|TestU01 (BigCrush)|14:BirthdaySpacings|9/9|
|JDK|TestU01 (BigCrush)|15:BirthdaySpacings|9/9|
|JDK|TestU01 (BigCrush)|16:BirthdaySpacings|9/9|
|JDK|TestU01 (BigCrush)|17:BirthdaySpacings|9/9|
|JDK|TestU01 (BigCrush)|18:BirthdaySpacings|9/9|
|JDK|TestU01 (BigCrush)|19:BirthdaySpacings|9/9|
|JDK|TestU01 (BigCrush)|20:BirthdaySpacings|9/9|
|JDK|TestU01 (BigCrush)|21:BirthdaySpacings|9/9|
|JDK|TestU01 (BigCrush)|22:ClosePairs|9/9|
|JDK|TestU01 (BigCrush)|23:ClosePairs|9/9|
|JDK|TestU01 (BigCrush)|24:ClosePairs|9/9|
|JDK|TestU01 (BigCrush)|25:ClosePairs|9/9|
|JDK|TestU01 (BigCrush)|26:SimpPoker|9/9|
|JDK|TestU01 (BigCrush)|28:SimpPoker|9/9|
|JDK|TestU01 (BigCrush)|30:CouponCollector|9/9|
|JDK|TestU01 (BigCrush)|31:CouponCollector|9/9|
|JDK|TestU01 (BigCrush)|34:Gap|9/9|
|JDK|TestU01 (BigCrush)|36:Gap|9/9|
|JDK|TestU01 (BigCrush)|40:Permutation|9/9|
|JDK|TestU01 (BigCrush)|41:Permutation|9/9|
|JDK|TestU01 (BigCrush)|42:Permutation|9/9|
|JDK|TestU01 (BigCrush)|43:Permutation|9/9|
|JDK|TestU01 (BigCrush)|44:CollisionPermut|9/9|
|JDK|TestU01 (BigCrush)|45:CollisionPermut|9/9|
|JDK|TestU01 (BigCrush)|46:MaxOft|9/9|
|JDK|TestU01 (BigCrush)|47:MaxOft|9/9|
|JDK|TestU01 (BigCrush)|48:MaxOft|9/9|
|JDK|TestU01 (BigCrush)|49:MaxOft|9/9|
|JDK|TestU01 (BigCrush)|50:SampleProd|9/9|
|JDK|TestU01 (BigCrush)|51:SampleProd|9/9|
|JDK|TestU01 (BigCrush)|52:SampleProd|9/9|
|JDK|TestU01 (BigCrush)|57:AppearanceSpacings|9/9|
|JDK|TestU01 (BigCrush)|59:WeightDistrib|9/9|
|JDK|TestU01 (BigCrush)|62:WeightDistrib|9/9|
|JDK|TestU01 (BigCrush)|63:WeightDistrib|9/9|
|JDK|TestU01 (BigCrush)|65:SumCollector|9/9|
|JDK|TestU01 (BigCrush)|74:RandomWalk1|9/9|
|JDK|TestU01 (BigCrush)|86:LongestHeadRun|9/9|
|JDK|TestU01 (BigCrush)|90:HammingWeight2|9/9|
|JDK|TestU01 (BigCrush)|95:HammingIndep|9/9|
|JDK|TestU01 (BigCrush)|97:HammingIndep|9/9|
|JDK|TestU01 (BigCrush)|99:HammingIndep|9/9|
|JDK|TestU01 (BigCrush)|101:Run|9/9|
|MT|TestU01 (BigCrush)|80:Line
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16697756#comment-16697756
]
Gilles commented on RNG-57:
---
No obvious regression was caused by implementing your proposal (cache). By
using all the generated bits, it made it harder to pass all the tests (maybe
that's why TWO_CMRES now fails one consistently). The refined testing which
you suggest, and more extensive statistics can be done as part of a new issue
(or a side project).
Can we resolve this issue?
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16699486#comment-16699486
]
Alex D Herbert commented on RNG-57:
---
bq. Can we resolve this issue?
Yes.
(I have been away so sorry for delayed reply.)
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700264#comment-16700264
]
Gilles commented on RNG-57:
---
bq. sorry for delayed reply.
No problem. Thank you for the thoughtful contribution.
> 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)
