[jira] [Created] (RNG-80) SplitMix64 to natively generate nextInt

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

Alex D Herbert created RNG-80:
---------------------------------

             Summary: SplitMix64 to natively generate nextInt
                 Key: RNG-80
                 URL: https://issues.apache.org/jira/browse/RNG-80
             Project: Commons RNG
          Issue Type: Improvement
          Components: core
    Affects Versions: 1.3
            Reporter: Alex D Herbert
            Assignee: Alex D Herbert


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.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)