Re:The Value of Undefined Behavior
by hsivonen on Saturday July 21, 2018 @05:23PM
(#17583925)
A crate that I wrote, encoding_rs uses unsafe for performance purposes (probably a bit more than absolutely necessary). I'd be very unhappy if unsafe compiled to slower code. The unsafe bits intermingle with safe Rust to such a degree that having to write them in C would make me very unhappy.
For the curious, the performance uses of unsafe in encoding_rs are roughly in these categories:
- Omitting Unicode correctness checks (i.e. asserting that output is correct without having the standard library re-check; Unicode correctness is part of the core competence of the crate).
- Viewing buffers of u8 or u16 as buffers of usize.
- Viewing buffers of u8 or u16 as SIMD register-sized units.
- Omitting bound checks where the compiler fails to elide them and it matters for performance, especially where the performance difference matters for competitiveness with C++.
- Reinterpreting SIMD registers in a different lane configuration. (Exposes endianness but otherwise actually safe.)
- Calling intrinsics that don't really have anything unsafe about them except that Rust makes intrinsics categorically unsafe instead of deciding on a case by case basis if they need to be unsafe.
Of these, viewing buffers as buffers of ALU or SIMD register-sized units are the only cases that come near strict aliasing and could be trouble if the compiler felt eligible to reorder writes of (in the C sense) incompatible types relative to each other on the assumption that buffers of different types are disjoint.
For the curious, the performance uses of unsafe in encoding_rs are roughly in these categories:
- Omitting Unicode correctness checks (i.e. asserting that output is correct without having the standard library re-check; Unicode correctness is part of the core competence of the crate).
- Viewing buffers of u8 or u16 as buffers of usize.
- Viewing buffers of u8 or u16 as SIMD register-sized units.
- Omitting bound checks where the compiler fails to elide them and it matters for performance, especially where the performance difference matters for competitiveness with C++.
- Reinterpreting SIMD registers in a different lane configuration. (Exposes endianness but otherwise actually safe.)
- Calling intrinsics that don't really have anything unsafe about them except that Rust makes intrinsics categorically unsafe instead of deciding on a case by case basis if they need to be unsafe.
Of these, viewing buffers as buffers of ALU or SIMD register-sized units are the only cases that come near strict aliasing and could be trouble if the compiler felt eligible to reorder writes of (in the C sense) incompatible types relative to each other on the assumption that buffers of different types are disjoint.