For some applications, Rust’s bounds checks and the inability of rustc to eliminate them in nontrivial cases will already be too much of a performance sacrifice. What do we say to those people? Is it just that memory safety is important because of its security implications, and other forms of program correctness are not?
I am wary of circling around on this topic again, but I feel that the biggest mistake in this discussion js that checked overflow in a language requires a potential trap on every single integer operation. Languages like Ada (and Swift, to a lesser extent), allow for slightly imprecise exceptions in the case of integer overflow. A fairly simple rule is that a check for overflow only needs to occur before the incorrect result may have externally visible side effects. Ada’s rule even lets you go a step further and remove overflow checks from loops in some cases (without violating control dependence of the eventual overflowing operation). One model like this that has been proposed for C/C++ is the “As Infinitely Ranged” model (see http://www.cert.org/secure-coding/tools/air-integer-model.cfm), where operations either give the result that would be correct if integers had infinite precision, or cause a trap. This allows for more optimizations to be performed, and although it is questionable to me whether they preserved control dependence of overflow behavior in all cases, they report a 5.5% slowdown on SPEC2006 with GCC 4.5 (compared to a 13% slowdown with more plentiful checks) using a very naive implementation. A lot of those checks in SPEC2006 could probably just be eliminated if the language itself distinguished between overflow-trapping and overflow-permissive operations. If a compiler optimizer understood the semantics of potentially trapping integer operations better (or at all), it could reduce the overhead of the checks. I know that some people don’t want to require new compiler techniques (or are afraid of relying on something outside of the scope of what LLVM can handle today), but it would be unfortunate for Rust to make the wrong decision here based on such incidental details rather than what is actually possible. Cameron On Jun 22, 2014, at 9:21 AM, Benjamin Striegel <[email protected]> wrote: > I apologize for being hostile. As Florian has noted, we're just arguing about > the default behavior here. It is my opinion that checked behavior by default > will make Rust unsuitable for filling C++'s niche, and send the message that > we are not serious about performance. > > > On Sun, Jun 22, 2014 at 12:10 PM, Evan G <[email protected]> wrote: > I don't think I was ever "Railing against the incorrectness of overflow > semantics"? I was just pointing out that your (imo pretty hostile?) message > about "If you don't require absolute speed, why are you using Rust?" doesn't > really ring true. Most C++ programmers don't even require absolute speed. > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
