[
https://issues.apache.org/jira/browse/RNG-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16785834#comment-16785834
]
Gilles commented on RNG-80:
---------------------------
bq. Is the intension of the algorithm to match exactly the SplittableRandom?
No.
I referred to the algorithm's "reference" implementation; the question was
whether the modified "SplitMix64" would generate sequences of "int" values that
would be different from the current implementation. And if so, is it
acceptable? IOW, is the reference only concerned with generation of "long"
values?
> 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)
