8 ms·
Yeah, their initial explanation is that its the "safety features", but I was under the impression that literally everything related to rust's safety happens at
by 013a 7y ago
Yeah, their initial explanation is that its the "safety features", but I was under the impression that literally everything related to rust's safety happens at compile time. Their big selling point is the "zero cost abstractions".
- atoav 7y agoWhile you are spot on with zero cost abstractions a bounds check in Rust is not without penalty (if enabled, should be off in release mode)
- __s 7y agoBounds checks are always on. Integer overflow checks are disabled in release mode. Bounds checks are necessary for memory safety, whereas integer overflow isn't
- kjeetgill 7y agoI believe release mode keeps bound checks. It's integer overflow checks it gets rid of.
- jnordwick 7y agoyou can't turn bounds checking off. there are unsafe method for vec that allow you unchecked access to the array, but you need to to write it in unsafe block (some code that is performance sensitive does this).
- mehrdadn 7y agoI don't know... while it may not be the case here, I wouldn't be exactly shocked if the fact that Rust restricts your ability to do some things ends up having a performance penalty, even if any safety checks themselves happen at compile time.
- Zarel 7y agoTheir initial explanation is bounds checking specifically. While most abstractions are zero-cost, bounds checking isn't. I do wish there were a way to track expectations about integer ranges in a type system, but there currently aren't.
- wbl 7y agoMight I intrest you in dependent types? Sadly we don't even have a self hosted compiler yet.
- Zarel 7y agoI really like dependent types as a concept! But they're not really in any mainstream languages, so I haven't had much opportunity to play around with them. :(
- steveklabnik 7y agoBounds checking is a “zero cost abstraction” in the sense that it is both “pay for what you use” and “you couldn’t implement it yourself any better.” That said, the implemention is not as fast as it theoretically can be, because the compiler isn’t always removing bounds checks that are provably true. When const generic lands, you will be able to make those assertions! A basic implementation is in nightly.
- jnordwick 7y agohow do you not use bounds checking? (unsafe like get_unchecked doesn't count because then you can say that about almost every rust feature).
- deleted 7y ago[deleted]
- steveklabnik 7y agoYou're mis-understanding what "you don't pay for what you don't use" means. It means that a program that does not contain [] in it does not include code for []. There's no "mandatory runtime" code for []. It doesn't mean you can use [] in some special way and somehow get less code. And even if we were talking about your understanding, I don't see why get_unchecked would be disqualified. unsafe is a part of the language for a reason.
- kzrdude 7y agoIt's never claimed that every abstraction in Rust is zero cost. Just that these are often possible.
- rstuart4133 7y agoThe explanation I heard from a Rust core dev (explain why Rust tends to be slightly slower than C++) is the borrow checker makes programmers to use a slightly different coding style. Were C programmers tend to pass references around Rust programmers tend to take copies of to avoid the borrow checker. Passing the smaller reference will be faster in single threaded code. In multi threaded code I'd expect making a thread local copy to be a win, and indeed multi threaded Rust programs tend to be quicker than their C/C++ counterparts.