How to fill allocated memory?

fn write_bytes<T>(dst: *mut T, val: u8, count: usize)

This function allows to fill the buffer with bytes (u8).
And how to fill it with values of an arbitrary type? For example, u32?
The usual loop works very slowly for large amounts of data.

Rust tries to avoid dangerous and overly general-purpose solutions like memset, so it'd be best to take a step back — what do you need to fill? If you want to initialize allocated memory, then vec![value; len] does this in the best way Rust can. There's also Vec::resize.

Even a naive loop shouldn't be slow. Rust has an optimizer (remember to build with --release). In modern architectures cost of touching memory is literally hundreds of times higher than cost of executing a few instructions, so naive loops will be limited by memory bandwidth anyway.

If you really need something very specific, you'll probably need slice::align_to and ptr::write or cpu-specific intrinsics (assuming the problem is too complex for optimizer to automatically vectorize it).

If amount of data you have is really large, it may be better not to naively write to it, but use system-specific virtual memory functions to lazily initialize it (Rust does that for 0-filled pages already).


Thank you for ideas!
And how "under the hood" works vec![value; len]? It works very quiqly!
For example, if I create my own data structure, it would be useful to know these details.

It uses some intrinsics, namely the unstable box syntax.

I was under this impression too, but upon some further digging, that's actually only true for the vec![value, value, value] form of the macro.

Under the hood, the [value; len] form of the vec! macro calls a function called from_elem, which uses the unstable specialization feature to either:

  • Do an optimized write if the value is a simple u8.
  • Zero the buffer if the value is numeric and set to zero.
  • Delegate to extend_with to fill the Vec otherwise.

There's a lot of clever unsafe code there, but other than the use of specialization to optimize for some special cases, it doesn't look like there's anything there that couldn't be implemented outside of the standard library :slight_smile:


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.