You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Alex D Herbert (JIRA)" <ji...@apache.org> on 2018/10/03 09:47:00 UTC
[jira] [Comment Edited] (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 edited comment on RNG-57 at 10/3/18 9:46 AM:
------------------------------------------------------------
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.
The results below are relative scores from a run of 1,000,000 samples using 10 warm-up iterations and 100 iterations. The RNG was randomly seeded each run. The relative score is the ratio of the cached version to the standard version using the average time reported by JMH.
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.504|
|MT_64|Mac|0.550|
|MT_64|Windows|0.527|
|MWC_256|Linux|0.698|
|MWC_256|Mac|0.689|
|MWC_256|Windows|0.700|
|SPLIT_MIX_64|Linux|0.821|
|SPLIT_MIX_64|Mac|0.916|
|SPLIT_MIX_64|Windows|0.725|
|TWO_CMRES|Linux|0.632|
|TWO_CMRES|Mac|0.724|
|TWO_CMRES|Windows|0.617|
|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.639|
|XOR_SHIFT_1024_S|Mac|0.732|
|XOR_SHIFT_1024_S|Windows|0.604|
Results for {{nextInt}}:
||RNG||Test||Relative||
|MT_64|Linux|0.767|
|MT_64|Mac|0.751|
|MT_64|Windows|0.767|
|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|
|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.
was (Author: alexherbert):
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)