Implement Fill for [MaybeUninit<T>]

[kangalio]

Background

What is your motivation? Right now, the Rng::fill function can only write to buffers that are already initialized. That's because passing uninitialized memory as a &[T] is undefined behavior. With an AsByteSliceMut implementation for [MaybeUninit<T>], rand could be used to write vast amounts of random numbers into memory without needing to zero out the memory before.

What type of application is this? Fast generation of vast amounts of numbers

Feature request

The rand::AsByteSliceMut trait should be implemented for all [MaybeUninit<T>] where T are the numeric integer types. In other words, similar to how you can fill a &mut [u32]/&mut [i32]/&mut [usize]/... or a &mut [Wrapping<u32>]/&mut [Wrapping<i32>]/&mut [Wrapping<usize>]/..., rand should support filling a &mut [MaybeUninit<u32>]/&mut [MaybeUninit<i32>]/&mut [MaybeUninit<usize>]/...

[dhardy]

Hmm, the problem there is that implementing AsByteSliceMut for [MaybeUninit<T>] gives a "safe" way to read uninitialised memory — as such the implementation would violate memory safety rules around unsafe, even if typical usage wouldn't.

Rand v0.8 has already replaced this trait with Fill which doesn't have this problem, so implementing that is fine (should you like to make a PR).

(Note also that to use MaybeUninit you have to use unsafe anyway, so you could just transmute to &mut [u8] yourself.)

[kangalio]

Rand v0.8 has already replaced this trait with Fill which doesn't have this problem, so implementing that is fine

Oh damn, that's what I get for forgetting to click the "Go to latest version" button on docs.rs.

That's good news then, I'm glad there's nothing in the way of this feature.

(Note also that to use MaybeUninit you have to use unsafe anyway, so you could just transmute to &mut [u8] yourself.)

Actually no, because it's undefined behavior in Rust to produce a mutable reference to uninitialized memory, even if it's not explicitly read from. That's because, when writing to the mutable reference, Rust will attempt to drop the previous contained value, which is uninitialized in this case. So a designated Fill implementation for [MaybeUninit<T>] is unfortunately required.

[kangalio]

Question about the source code: in the Fill trait's try_fill implementations, after the slice has been filled with random data, all the elements are turned to little endian. Why? The bytes are completely random anyways, it makes no difference if they're little-endian or big-endian.

rand/src/rng.rs

Lines 350 to 358 in 98a1aaf

	rng.try_fill_bytes(unsafe {
	slice::from_raw_parts_mut(self.as_mut_ptr()
	as *mut u8,
	self.len() * mem::size_of::<$t>()
	)
	})?;
	for x in self {
	*x = x.to_le();
	}

[newpavlov]

This trait is also used by PRNGs and for some applications (e.g. games) it's important to keep RNG output reproducible on different platforms.

[kangalio]

Currently, the API of RngCore can only fill &mut [u8]. However, it is undefined behavior to have a &mut [u8] pointing to uninitialized memory, therefore RngCore in its current state does not support filling uninitialized bytes.

In order to implement the feature proposed in this issue, a new method would need to be added to RngCore:

pub fn try_fill_uninitialized_bytes(&mut self, dest: &mut [MaybeUninit<u8>]) -> Result<(), Error>

What do the rand maintainers think about this suggestion?

[dhardy]

I'd really prefer not to go that route since (a) we want to keep RngCore minimal and (b) avoid breaking changes to rand_core.

How much performance overhead is there if you copy to a buffer first? The compiler may even optimise the extra copy away, and in many cases the perf. isn't critical anyway.

[dhardy]

Of course at this point you might as well just use a zeroed array to start with and avoid using MaybeUninit at all.

If we really need to redesign the core RNG for better performance here, it would be better to look at making BlockRngCore::generate take ptr: *mut u8, len: usize and use this trait directly for filling the uninit array. But I don't think we need to consider that yet. (And in this case, you could just consider your use-case special and write a custom RNG for it. But only if you really need to fully optimise this case.)

[vks]

This should probably be backed up by a benchmark demonstrating the performance advantage.

[newpavlov]

We also probably should wait for rust-lang/rust#78485 to be implemented and use the proposed ReadBuf type.

[dhardy]

The ReadBuf RFC now has an impl PR but it is not merged. Assuming this does get stabilised, we could add a method like the following to RngCore:

fn try_fill_read_buf(&mut self, buf: &mut ReadBuf<'_>) -> Result<(), Error> {
    self.try_fill_bytes(buf.initialize_unfilled());
}

This is non-breaking and fairly low complexity, but still an addition to what is supposed to be a simple core trait.

What are our thoughts on this? Mine is that a benchmark demonstrating significant improvement is required. I guess it would be interesting to look at both something like SmallRng and something stronger like ChaCha8Rng.

[newpavlov]

I think it may be useful to have fill methods for u32/u64. In some (AFAIK relatively rare) cases they may result in a significant acceleration, especially for PRNGs like ChaCha which can use SIMD to produce several blocks in parallel. Also they should result in less memory stores if a PRNG state can fit into registers. Those methods could replace the next_* methods, by marking the fill methods #[inline] the &mut [T; 1] case should be trivially optimizable by compiler. And it also should be possible to introduce them gradually (introduce them implemented in terms of next_* first, then mark next_* methods deprecated, and eventually remove them in the next breaking release), limiting the migration churn.

I am significantly less sure about benefits of supporting uninitialized memory. First it should be demonstrated that zero-filling initialization indeed does not get optimized out for our PRNGs, I will not be surprised if it does (but note that compiler should not be able to perform such optimization for OsRng). And even if it does not, I think that potential performance loss will be miniscule, especially if user code properly reuses buffers.

[vks]

@newpavlov Isn't fill_bytes supposed to fill that niche? I suppose that it might not due to alignment issues.

I think it might make sense to improve Distribution to better support vectorization as well.

[newpavlov]

@vks
It indeed fills this niche right now, but its drawbacks not only the alignment issue which can reduce performance a bit, but also the fact that we have to compensate for endianness outside of the fill method, which on BE targets results in a two-pass approach. Plus I don't quite like the possibility of potentially different results for filling slice via the next_* methods and via the Fill trait.