rust-random / rngs Goto Github PK
View Code? Open in Web Editor NEWExtra RNGs
License: Other
Extra RNGs
License: Other
Many of the xorshiro
generators, such as Xorshiro256Plus
, have a method called jump
that allows the RNG to generate different sequences in parallel applications. However, I'm not sure how to actually use jump
for parallel computing, and the examples don't really show much. Can someone provide an example of the jump
API being used in parallel computing?
I'm trying to use XorShiftRng
just as a simple and quick stream of reproducible random bytes (I don't really need cryptographic security for this) and want to be able to serialize it so that I can load it in the same state at a later point in time.
I can't seem to see any way to do this. Would it be okay to submit a PR that adds a conditional Cargo feature that makes XorShiftRng
derive serde::Serialize
and serde::Deserialize
? Or alternatively add something like a to_seed(&self)
method that can be used to reconstruct the XorShiftRng
via the SeedableRng
trait?
Anything from rand with a trait bound that requires Rng doesn't work. It looks like the Rng trait became a part of rand and this was never updated?
See: https://espadrine.github.io/blog/posts/shishua-the-fastest-prng-in-the-world.html
That looks cool, but I don't know anything about rngs so I'm sure there's a reason against adding it. If not, would a Rust port be welcome?
There is some discussion on how to vectorize xoshiro256++ at JuliaLang/julia#27614. The method relies on interleaving 4 xoshiro256++ generators. I implemented it and the results are impressive (see gen_bytes_fill
):
test gen_bytes_chacha12 ... bench: 324,494 ns/iter (+/- 4,236) = 3155 MB/s
test gen_bytes_chacha20 ... bench: 490,442 ns/iter (+/- 16,214) = 2087 MB/s
test gen_bytes_chacha8 ... bench: 243,010 ns/iter (+/- 19,972) = 4213 MB/s
test gen_bytes_fill ... bench: 105,350 ns/iter (+/- 1,456) = 9719 MB/s
test gen_bytes_pcg64mcg ... bench: 321,665 ns/iter (+/- 7,854) = 3183 MB/s
test gen_bytes_splitmix64 ... bench: 233,973 ns/iter (+/- 1,859) = 4376 MB/s
test gen_bytes_xoshiro256plusplus ... bench: 343,911 ns/iter (+/- 6,580) = 2977 MB/s
The implementation is 3.3 time faster than the non-vectorized xoshiro256++ generator and more than 2.2 times faster than splitmix64 or chacha8. It is also faster than dSFMT. However, the size of the state is blown up to 128 bytes, which is almost as large as chacha's state (136 bytes).
CI fails since the current MSRV is 1.36, but syn requires 1.56. We either need to bump the MSRV or pin dependency versions when testing this.
When seeded with zero, xorshift is silently seeded with a different value:
Lines 86 to 91 in 7cda1f8
The docs don't mention this though.
When seeding from another RNG, the situation is even worse: if the seeding RNG keeps returning zeroes, xorshift's initialization will loop forever:
Lines 102 to 108 in 7cda1f8
from_rng
is fallible, so it could perform a limited number of iterations and fail if it can't get a non-zero seed.
I think that, at the very least, these behaviours should be documented.
It would seem that rand_xoshiro
0.4.0 is incompatible with rand_core
0.6.0.
Options for documentation:
rand
repo's Travis doc builderHello,
Can you update the crate in crates.io to be in sync with rand_core
version 0.6 in this repo?
Currently we can't use rand
version 0.8 and rand_core
version 0.6 from crates.io.
The latest version of the docs indicate the following:
This implementation is not based on the version of HC-128 submitted to the eSTREAM contest, but on a later version by the author with a few small improvements from December 15, 20094.
The footnote in the docs link to this reference that no longer exists - https://www.ntu.edu.sg/home/wuhj/research/hc/index.html
However, using the Internet Archive, we can see the page, with the last modified date of December 15, 2009 - https://web.archive.org/web/20110527154230/https://www.ntu.edu.sg/home/wuhj/research/hc/index.html
This webpage is general and does not directly outline said "small improvements" by the author of HC-128.
The current docs do not transparently reflect which version of HC-128 is implemented in rand_rc
. The Rust Random book specifically mentions that HC-128 is recommended by eSTREAM, though this crate is using an implementation that is NOT recommended by eSTREAM.
This creates a false sense of security for those who may be relying on the guarantees and analysis that the eSTREAM project provided. eSTREAM did not provide analysis/review/approval/recommendation of the "small improvements" version that is vaguely referenced in the docs for rand_rc
.
Because of this, the docs need to better reflect which implementation is being used and MUST be very clear that the recommendation by eSTREAM is misleading. I do not believe that the cryptanalysis of HC-128 as it relates to eSTREAM can be assumed to be valid for this optimized version with "small improvements".
The winapi crate no longer appears to be maintained and there are now official windows/windows-sys crates from Microsoft. As such rand_jitter should probably transition from using winapi to windows/windows-sys.
I ran into this issue when using Xoshiro128Plus:
error[E0599]: no method named `long_jump` found for struct `Xoshiro128Plus` in the current scope
--> src/lib.rs:65:26
|
65 | self.xoshiro128p.long_jump();
| ^^^^^^^^^ method not found in `Xoshiro128Plus`
The C reference code does include a long_jump()
, and the code is practically the same as for xoshiro128++.
criterion-cycles-per-byte
provides benchmarks with cycles per byte, which would be more appropriate for RNGs than bytes per second.
There has been a lot of discussion about what to do about SmallRng, when special instructions such as aes-ni is not available:
rust-random/rand#910, rust-random/rand#767, rust-random/rand#603
Previously it was PCG, but there were some issues:
rust-random/rand#907, rust-random/rand#905
Including the small state. It was switched to Xoshiro which was an improvement but is still not ideal.
I set about creating a better option for this case.
I've written up the design and more about the motivation here:
https://tom-kaitchuck.medium.com/designing-a-new-prng-1c4ffd27124d
Explanation of quality is detailed there as well.
The code is checked in here:
https://github.com/tkaitchuck/Mwc256XXA64
@rust-random If there is agreement that this is worth adding as an option I can create a PR to add a rand_mwc
crate.
I want to use rand::Rng::sample
on JitterRng
. Using the latest versions on crates.io (rand_jitter=0.3.0
and rand=0.8.5
), this doesn't work because rand
and rand_jitter
are using different versions of rand_core
(0.5
and 0.6
respectively). The rand_core
dependency for rand_jitter
has already been updated on main, but it seems like no new release to crates.io was done afterwards.
Could you please release a new version of rand_jitter
? I'm using rand_jitter
as a git dependency in the meantime, but it'd be nice to go back to a crates.io dependency eventually.
Thanks in advance!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.