[
https://issues.apache.org/jira/browse/RNG-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16785812#comment-16785812
]
Alex D Herbert commented on RNG-80:
-----------------------------------
{quote}Does it modify the generated sequence?
{quote}
The output of {{int}} from {{java.util.SplittableRandom}} will be different to
the implementation in {{SplitMix64}}. The {{long}} output is the same.
Is this what you mean?
I noticed this variant when browsing the source and thought I should
investigate if it was faster.
The {{int}} output from {{SplitMix64}} uses the upper and lower bits of the
{{long}} sequence to generate {{int}} since 1.2. Before that the upper and
lower 32-bits were combined with xor (IIRC). So the algorithm was never the
same for {{int}}.
This passes the 3 benchmark runs for DieHarder and has 2 non-systematic
failures for BigCrush.
Is the intension of the algorithm to match exactly the SplittableRandom?
> 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)
