[
https://issues.apache.org/jira/browse/RNG-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex D Herbert updated RNG-80:
------------------------------
Description:
The {{SplitMix64}} currently uses the {{LongProvider}} implementation of
{{nextInt}} to split the {{long}} into two {{int}} values.
However it is possible to generate {{int}} values using a variant of the
algorithm which uses a different mixing function:
{code:java}
/**
* Computes Stafford variant 13 of 64bit mix function.
*
* @return the long
*/
public final long nextLong() {
long z = state += 0x9e3779b97f4a7c15L;
z = (z ^ (z >>> 30)) * 0xbf58476d1ce4e5b9L;
z = (z ^ (z >>> 27)) * 0x94d049bb133111ebL;
return z ^ (z >>> 31);
}
/**
* Returns the 32 high bits of Stafford variant 4 mix64 function as int.
*
* @return the int
*/
public final int nextInt() {
long z = state += 0x9e3779b97f4a7c15L;
z = (z ^ (z >>> 33)) * 0x62a9d9ed799705f5L;
return (int)(((z ^ (z >>> 28)) * 0xcb24d0a5c88c35b3L) >>> 32);
}
{code}
This variant is used in {{java.util.SplittableRandom}}. It changes the second
shift operation and omits a xor operation.
A benchmark should be made to test if the variant is faster than the current
method to cache the long and split it into two values.
Note that the investigation of the speed of caching was performed in RNG-57.
The first entry on this post shows the cache only marginally improves (5%) the
speed of the {{SplitMix64}} generator. Updating the native generation using a
faster algorithm with less mixing may outperform the cache.
was:
The {{SplitMix64}} currently uses the {{LongProvider}} implementation of
{{nextInt}} to split the {{long}} into two {{int}} values.
However it is possible to generate {{int}} values using a variant of the
algorithm which uses a different mixing function:
{code:java}
/**
* Computes Stafford variant 13 of 64bit mix function.
*
* @return the long
*/
public final long nextLong() {
long z = state += 0x9e3779b97f4a7c15L;
z = (z ^ (z >>> 30)) * 0xbf58476d1ce4e5b9L;
z = (z ^ (z >>> 27)) * 0x94d049bb133111ebL;
return z ^ (z >>> 31);
}
/**
* Returns the 32 high bits of Stafford variant 4 mix64 function as int.
*
* @return the int
*/
public final int nextInt() {
long z = state += 0x9e3779b97f4a7c15L;
z = (z ^ (z >>> 33)) * 0x62a9d9ed799705f5L;
return (int)(((z ^ (z >>> 28)) * 0xcb24d0a5c88c35b3L) >>> 32);
}
{code}
This variant is used in {{java.util.SplittableRandom}}. It changes the second
shift operation and omits a xor operation.
A benchmark should be made to test if the variant is faster than the current
method to cache the long and split it into two values.
Note that the investigation of the speed of caching was performed in
[RNG-57|https://issues.apache.org/jira/browse/RNG-57]. The first entry on this
post shows the cache only marginally improves (5%) the speed of the
{[SplitMix64}} generator. Updating the native generation using a faster
algorithm with less mixing may outperform the cache.
> Benchmark SplitMix64 to natively generate nextInt
> -------------------------------------------------
>
> Key: RNG-80
> URL: https://issues.apache.org/jira/browse/RNG-80
> Project: Commons RNG
> Issue Type: Task
> Components: core
> Affects Versions: 1.3
> Reporter: Alex D Herbert
> Assignee: Alex D Herbert
> Priority: Minor
>
> The {{SplitMix64}} currently uses the {{LongProvider}} implementation of
> {{nextInt}} to split the {{long}} into two {{int}} values.
> However it is possible to generate {{int}} values using a variant of the
> algorithm which uses a different mixing function:
> {code:java}
> /**
> * Computes Stafford variant 13 of 64bit mix function.
> *
> * @return the long
> */
> public final long nextLong() {
> long z = state += 0x9e3779b97f4a7c15L;
> z = (z ^ (z >>> 30)) * 0xbf58476d1ce4e5b9L;
> z = (z ^ (z >>> 27)) * 0x94d049bb133111ebL;
> return z ^ (z >>> 31);
> }
> /**
> * Returns the 32 high bits of Stafford variant 4 mix64 function as int.
> *
> * @return the int
> */
> public final int nextInt() {
> long z = state += 0x9e3779b97f4a7c15L;
> z = (z ^ (z >>> 33)) * 0x62a9d9ed799705f5L;
> return (int)(((z ^ (z >>> 28)) * 0xcb24d0a5c88c35b3L) >>> 32);
> }
> {code}
> This variant is used in {{java.util.SplittableRandom}}. It changes the second
> shift operation and omits a xor operation.
> A benchmark should be made to test if the variant is faster than the current
> method to cache the long and split it into two values.
> Note that the investigation of the speed of caching was performed in RNG-57.
> The first entry on this post shows the cache only marginally improves (5%)
> the speed of the {{SplitMix64}} generator. Updating the native generation
> using a faster algorithm with less mixing may outperform the cache.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
