It's meant to bother people. It was intended to add friction to depending on wrapping and to keep people aware that it's a bug to have unmarked overflows. The language can't accept the significant cost of having overflow checks enabled by default today but wants to do it later.
-
-
Replying to @DanielMicay @robotlolita
Intel supports the carry and overflow flags. It's nearly free to detect wrapping. Even if they didn't, modern CPU performance is dictated by memory latency. Any extra computation that doesn't do extra fetches is close to free.
1 reply 0 retweets 0 likes -
Replying to @andreasdotorg @robotlolita
That's not the kind of hardware support I'm talking about. You can enable overflow checking and see for yourself that it has a significant performance and code size cost despite using the available intrinsics / hardware support.
1 reply 0 retweets 0 likes -
Having overflow checks for all arithmetic operation blocks many other optimizations which hurts much more in idiomatic Rust than C. Branches and larger code size hurt overall performance by wasting global resources. The bounds checks are already expensive but not quite as bad.
1 reply 0 retweets 0 likes -
The decision involved a lot of people reviewing potential compromises and data on performance. It was a frequent topic and the unfortunate reality is the current compiler and hardware support is very inadequate for the performance tier Rust wants to compete in by default.
1 reply 0 retweets 0 likes -
Replying to @DanielMicay @robotlolita
Unfortunate indeed. I hope feedback has been given to hardware vendors. Thanks for the explanation!
1 reply 0 retweets 0 likes -
Replying to @andreasdotorg @robotlolita
MIPS has trapping versions of the arithmetic instructions so it avoids extra code size but that would likely still have a fair bit of overhead in a modern CPU and the compiler would still miss optimizations. A lot of work needs to be done to eliminate the overhead.
2 replies 0 retweets 0 likes -
A language can be very helpful by supporting lazy semantics for the overflow errors, i.e. allow propagating them and only reporting an error when the overflow would have a side effect. Rust is meant to support that more efficient model, and ideally it'd be implemented for LLVM.
1 reply 0 retweets 0 likes -
The CPU architecture could potentially support a lazy trapping model for that to map onto too. I don't know how helpful that would be compared to just having alternate instructions with trapping on overflow. It can make a huge difference for compiler optimizations though.
1 reply 0 retweets 0 likes
The thing about trapping instructions is that they insert phantom edges into the control flow graph. I can see why compilers don't like that. Now if integers had a NaN like floats do...
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.