While on this microbenchmark you see a 3x slowdown with the LLVM backend, on large Rust projects like servo, Firefox, the rust compiler, etc. the slowdown is not even measurable.
Also, Rust provides you with unsafe intrinsics to opt-out of trapping in the particular line of code in which it causes an issue.
[0] https://play.rust-lang.org/?version=stable&mode=release&edit...
These two are not the same thing.
>> Rust wraps in release mode and traps in debug mode
You wrote:
> In release mode, the behavior of integer overflow in Rust is not UB/cannot happen, but modulo two arithmetic.
The parent didn't claim or imply that overflow is UB. The parent wrote that it "wraps", which is equivalent to your "modulo two arithmetic". You are not in disagreement, so why are you disagreeing?
“Hack” is a completely unsuitable term, there’s a simple and official compilation flag which can be flipped on or off.
It’s also misleading to say that Rust will trap on overflow: rustc enables overflow checking by default in debug mode, but disables it in release.
That flag changes the behavior of integer overflow from trapping to “modulo 2 arithmetic”.
If you want to change the behavior of integer overflow in Rust to “always assume it cannot happen”, you need to “hack” the compiler AFAIK.
If you believe this is incorrect, provide the flag that proves that (hint: such a flag makes safe Rust unsound and it therefore does not exist).
I've never claimed any such thing. Integer overflow is defined in Rust.
> That flag changes the behavior of integer overflow from trapping to “modulo 2 arithmetic”.
Yes?
> If you want to change the behavior of integer overflow in Rust to “always assume it cannot happen”, you need to “hack” the compiler AFAIK.
What I quoted was about rust "trapping" on integer overflow and having to "hack" it in order to make it not trap.
I'm assuming the rationalization is "wrapping is better than undefined behaviour" but I have not seen any evidence that the average program is actually more likely to behave correctly in the face of wrapping.
The combinations that make the most sense to me are:
1. debug: trap, release: trap. Bad performance, correct.
2. debug: wrap, release: wrap. Good performance
3. debug: trap, release: undefined. Great performance.
I guess my point is make up your mind. Is "overflow" allowed and wrapping or a bug?
Rust takes a simple stance of "safe code should be UB-free".
Yes, you may have logic bugs with wrapping, but you can't cause memory unsafety with it in, because things like array/slice bound checks aren't ever disabled.
Also, C relies on undefined signed overflow for things like "`for` loops incorrectly using `int` instead of `size_t` because it's easier to type", which doesn't really apply to Rust (which require `usize`, the `size_t` equivalent, for indexing, and has pointer-range-based iterators for slices), so I doubt UB overflow in Rust would help performance much.
It would be trivial to change `rustc_codegen_llvm` to set LLVM's `nsw`/`nuw` (in order to make signed/unsigned overflow UB), if you want to prove it improves performance somewhere.
Also the wrapping types aren't unsafe, they just make it explicit.
These two are not the same thing. See my reply to masklin.