Benchmark SplitMix64 to natively generate nextInt

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:

/**
 * 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);
}

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.