rust-random / rngs Goto Github PK

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 #15 and #13.

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:

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:

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:

1. Keep all doc under the https://rust-random.github.io/rand/ by use of cloning the repo and hacking the Cargo.toml in the rand repo's Travis doc builder
2. Use only docs.rs for these crates
3. Other?

Hello,

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.

Background:

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.

Concern:

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.

Background

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.

Design

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!