commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (RNG-80) Benchmark SplitMix64 to natively generate nextInt
Date Wed, 06 Mar 2019 16:07:00 GMT

    [ https://issues.apache.org/jira/browse/RNG-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16785800#comment-16785800
] 

Gilles commented on RNG-80:
---------------------------

bq. This variant is used in java.util.SplittableRandom. It changes the second shift operation
and omits a xor operation.

Does it modify the generated sequence?

bq. So the overhead of storing and checking the cache outperforms generating new int values.

So: no change?

> 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)

Mime
View raw message