On 22/06/14 05:12 PM, Cameron Zwarich wrote: > 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?
Rust's goal has been to bring modern language features to the systems programming world (sum types, traits, pattern matching) and make the necessary sacrifices to achieve memory safety. Rust isn't intended to be all things to all people. Most of the complexity budget has been spent providing memory safety without making performance sacrifices. Bounds checks are already one of the most serious barriers to adoption as a replacement for C and C++. A lot of effort will need to go into exposing safe APIs (like iterators) for sidestepping this overhead. At the moment, the unchecked indexing methods are required in many cases to avoid a large performance loss relative to C and the code ends up being far uglier than it would have been in C. Rust could provide checked arithmetic, but it can't make use of it in the standard libraries. It wouldn't improve the safety of the language because any performance critical low-level code using `unsafe` is going to want to avoid paying the cost of bounds checks. It's not simply a language issue, because libraries would need to expose methods with and without the overflow checks whenever they're doing arithmetic with the parameters. > 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. Graydon was always adamant that the language should use proven techniques and should avoid depending on a non-existent compiler optimization or immature research. For a language calling itself pragmatic, it has certainly spent a great deal of time getting to 1.0 and already ventures a fair bit outside of proven techniques (lifetimes). The focus should be on releasing an elegant language with memory safety and competitive performance with C++. Adding new features to the language at this point rather than refining the existing ones would be a huge mistake. A feature like checked arithmetic or tail call elimination can and should go through experiments behind feature gates, but it doesn't belong in a 1.0 release. If you don't agree with the fundamental language design at this point, that's too bad because it's 6 months away from 1.0 and you're too late.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
