Why use from_bytes when you can use pod_read_unaligned?

[JonathanWilbur]

Is there a performance benefit? I had a runtime failure because a slice wasn't aligned when using from_bytes, but it wasn't a problem when I used pod_read_unaligned.

[zachs18]

from_bytes returns a &T, whereas pod_read_unaligned returns a T, so for large types it may be more performant to use from_bytes if you don't need an owned value.

If you are immediately dereferencing the &T returned from from_bytes to get an owned value anyway, then pod_read_unaligned is probably better, which I suppose could be added to the docs if it isn't already.

[Lokathor]

Yes in addition to what zachs said, read_unaligned, the underlying primitive used by pod_read_unaligned, has much worse performance on targets where "actual" unaligned reads aren't allowed at all, such as ARM. In those situations, the "one read" has to be split up into multiple single-byte reads which are then merged within a register via bit shifting, so that no individual CPU access is ever misaligned.

[JonathanWilbur]

Okay. Maybe this should be a separate question, but how do I make a slice aligned? I tried using from_bytes on a slice from index 0 to index sizeof which I would have thought would be aligned. Is there some way to guarantee the alignment of the slice?

[Lokathor]

The usual way is to allocate it as the more aligned type, then convert to the less aligned type when you need to work in the less aligned type.

For example, allocate a vec of u64, then if you need it as a buffer of u16 values use cast_slice or cast_slice_mut

[JonathanWilbur]

Okay, that makes sense. Thank you! I will close this.