fill_via_chunks: mutate src on BE (small optimisation)

[dhardy]

This is an API-breaking change to rand_core but not too consequential, and results in a small performance boost on Big Endian:

From:
test gen_bytes_chacha12      ... bench:     367,282 ns/iter (+/- 265) = 2788 MB/s
test gen_bytes_chacha20      ... bench:     504,012 ns/iter (+/- 6,271) = 2031 MB/s
test gen_bytes_chacha8       ... bench:     296,971 ns/iter (+/- 1,062) = 3448 MB/s

To:
test gen_bytes_chacha12      ... bench:     334,430 ns/iter (+/- 2,287) = 3061 MB/s
test gen_bytes_chacha20      ... bench:     470,403 ns/iter (+/- 1,755) = 2176 MB/s
test gen_bytes_chacha8       ... bench:     262,490 ns/iter (+/- 1,313) = 3901 MB/s

LE is essentially unchanged:

test gen_bytes_chacha12      ... bench:     298,710 ns/iter (+/- 2,715) = 3428 MB/s
test gen_bytes_chacha20      ... bench:     436,912 ns/iter (+/- 4,788) = 2343 MB/s
test gen_bytes_chacha8       ... bench:     229,400 ns/iter (+/- 3,040) = 4463 MB/s

All numbers are smaller than expected due to #1181.

Since BE is not very popular and it's not that big a bump, we may choose not to merge this.

[dhardy]

Updated with documentation and rebase.

The code is significantly nicer so probably worth merging this (when we accept breaking changes).

[vks]

Looks good! I think this only needs a CHANGELOG update.

[dhardy]

This is a breaking change to rand_core, not rand. Are we planning a breaking release of that soon? There likely will be before 1.0 (at least @newpavlov has some ideas) but I've no idea what the schedule for that will be (or whether we want another breaking release of rand_core for rand v0.9).

[vks]

A breaking change to rand_core is a breaking change to rand, so it would make sense to synchronize them, wouldn't it?

[newpavlov]

One thing which I would like to do before releasing rand_core v1.0 is to merge BlockRng/BlockRng64 into a single wrapper type and changeBlockRngCore to:

pub trait BlockRngCore {
    type Item: SealedTrait;
    const ITEMS: usize;
    fn generate(&mut self) -> [Self::Item; Self::ITEMS];
}

It's possible today on Nightly with generic_const_exprs, but, unfortunately, it has no clear stabilization timeline.

Such trait still has a certain deficiency around target features, e.g. IIRC with ChaCha we have to use ChaCha block size multiplied by maximum number of blocks which could be generated in parallel (i.e. on non-AVX2 targets code will be a bit less efficient than possible), but we probably can overlook it. In RustCrypto we "solved" it using emulation of rank-2 closures, but such solution is somewhat complex and does not fit well into the rand use-case (when you use as a stream cipher you usually consume many blocks at once, while with RNG you often generate u32/u64s one by one).

[dhardy]

so it would make sense to synchronize them, wouldn't it?

More to the point, a breaking release of rand_core requires a breaking release of rand, but not vice versa.

So we can't release rand_core v1.0 for a while yet (also dependant on getrandom); the question is whether we want to make a breaking release soon or hold off on it for now.

If we didn't make a breaking release of rand_core, we wouldn't need to bump the RNG crates either.

[dhardy]

Breaking changes to rand_core are planned, so this will be rebased + merged soon.