New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8248862: Implement Enhanced Pseudo-Random Number Generators #1292
Conversation
Clean up javadoc.
Added selection criteria.
Remove non-ASCII character from RandomTestBsi1999 test.
Reworked how properties are handled.
Fixing testing.
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.
Remove PreviewFeature.Feature.RANDOM_NUMBERS
Tighten up RandomGeneratorFactory parameter
Remove stray @Preview comment
Move RandomSupport to jdk.internal.util.random
Removed extraneous import
Typos in Javadoc
Hide RandomSupport in Javadoc
Remove internal references
remove RandomGeneratorProperty from API
Clear up javadoc
Move RandomGeneratorProperty
Updated documentation for RandomGeneratorFactory.
Updated RandomGeneratorFactory javadoc.
Update package-info.java
|
@JimLaskey The following labels will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command. |
Has anyone here benchmarked this? I've run BumbleBench benchmarks (one of the AdoptOpenJDK team's tools, available here) and I'm skeptical of the original claims in JEP 356, namely:
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:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. 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
|
/integrate |
@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. |
The package javadoc of java.util.random says that |
|
This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
old PR: #1273
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292
$ git checkout pull/1292
Update a local copy of the PR:
$ git checkout pull/1292
$ git pull https://git.openjdk.java.net/jdk pull/1292/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 1292
View PR using the GUI difftool:
$ git pr show -t 1292
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/1292.diff