8248862: Implement Enhanced Pseudo-Random Number Generators #1292
Remove non-ASCII character from RandomTestBsi1999 test.
Reworked how properties are handled.
New test test/jdk/java/util/Random/RandomCanaryPi.java
Remove L32X64StarStarRandom and MRG32k3a
Remove export of additional random number generators
Move RandomSupport to java.util.random.internal.
Tighten up RandomGeneratorFactory parameter
Move RandomSupport to jdk.internal.util.random
remove RandomGeneratorProperty from API
Updated documentation for RandomGeneratorFactory.
Updated RandomGeneratorFactory javadoc.
On my machine, L64X128MixRandom's algorithm is 53% slower than SplittableRandom, a halving in performance that I think would be inaccurate to describe as "almost as fast." I've benchmarked on Java 8 HotSpot (Windows 10, x64) and Java 15 OpenJ9 (same machine). On HotSpot, which I think is the main concern, I go from 1021770880 (over 1 billion) random longs per second with SplittableRandom to 479769280 (over 479 million) with my (I believe faithful) implementation of L64X128MixRandom. That is where I observed the 53% reduction. While SplittableRandom specifically seems to perform relatively badly on OpenJ9, with 893283072 longs per second (893 million), other similar random number generators do extremely well on OpenJ9; LaserRandom generates 4232752128 random longs per second (4.2 billion) where L64X128MixRandom gets 840015872 (840 million). My benchmark repo is a mess, but if anyone wants to see and verify, here it is. JMH benchmarks might provide different or just additional useful information; I've only run BumbleBench.
One could make the argument that getting a random long from a PRNG takes so little time in the first place that it is unlikely to be a bottleneck, and by that logic, LXM is "almost as fast." However, if random generation is not being called often enough for its speed to matter, you are exceedingly unlikely to need so many (over 9 quintillion) parallel streams or such a long period per stream ((2 to the 192) minus (2 to the 64)). LXM is also 1-dimensionally equidistributed, while the foundation it is built on should allow 4-dimensional equidistribution (with the caveat of any LFSR that an all-zero state is impossible), with the same memory use per generator (4 longs), a longer period, and comparable quality using
If I were implementing a PRNG to operate in a future official version of the JVM, I would definitely look into ways to use AES-NI, and I think the interfaces provided here should be valuable for any similar addition, even if I disagree with the provided implementations of those interfaces. Thank you for your time.
Added the filter.
Thanks for this feedback. -- Guy
@JimLaskey This change now passes all automated pre-integration checks.
After integration, the commit message for the final commit will be:
At the time when this comment was updated there had been 1 new commit pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the
@JimLaskey Since your change was applied there has been 1 commit pushed to the
Your commit was automatically rebased without conflicts.
Pushed as commit a0ec2cb.