Re: [rust-dev] Compiling with no bounds checking for vectors?
Devs, please explain how such option could decrease the safety of the language. As it would be just that, an option, an opt-in one. IMHO it even could increase the safety of Rust. There are some extreme optimizing C++ programmers currently. Yes, they are a small fraction, but they exist. And they may want to switch to Rust too. What would they do in Rust? Use 'unsafe' everywhere? Think about library developers, who may not know how deep in loops their procedures will be used. But if there was such an option, then they could code most stuff as safe; they could enjoy the runtime checks during development, saving lots of debugging time; and switch them off only in the last build. I admit I am very noob in Rust. I do not want to push. I am just curious about your thinking. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 29/03/14 08:53 AM, Zoltán Tóth wrote: Devs, please explain how such option could decrease the safety of the language. As it would be just that, an option, an opt-in one. IMHO it even could increase the safety of Rust. There are some extreme optimizing C++ programmers currently. Yes, they are a small fraction, but they exist. And they may want to switch to Rust too. What would they do in Rust? Use 'unsafe' everywhere? Think about library developers, who may not know how deep in loops their procedures will be used. But if there was such an option, then they could code most stuff as safe; they could enjoy the runtime checks during development, saving lots of debugging time; and switch them off only in the last build. I admit I am very noob in Rust. I do not want to push. I am just curious about your thinking. Yes, you should use `unsafe` if you want unchecked indexing. You need to carefully think about each location this is done. In general, an out of bounds failure is considered a *runtime error*, not a logic error. It is not incorrect to write code indexing out of bounds, just like it is not incorrect to write code attempting to parse an integer and failing when it is invalid. A library author should not be lazy to the point where they *assume* every indexing operation, including those expanded from third party macros, is guaranteed to never go out of bounds regardless of the input given to the library functions. If they want to remove the bounds checks, they need to actually think about whether this holds for each one. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 2014.03.29 13:53:49 +0100, Zoltán Tóth wrote:
Devs, please explain how such option could decrease the safety of the
language. As it would be just that, an option, an opt-in one.
As somebody else said before, rust's indexing operator is like C++'s
std::vector::at() which throws an exception in case of an invalid index
that may be caugth to provide proper error handling. In C++ the switch
that is being proposed would kill the exception and would therefore also
render the error handler useless.
In rust, consider something like this:
use std::io::{BufferedReader, stdin};
use std::from_str::FromStr;
static values: [int, ..5] = [1,2,3,4,5];
fn main() {
let mut stdin = BufferedReader::new(stdin());
println!(Enter an index: );
for line in stdin.lines() {
match line {
Ok(l) = {
spawn(proc() {
let idx: int = FromStr::from_str(l.trim()).expect(Not
a number);
println!(The value at {} is {}, idx, values[idx]);
})
}
_ = {}
}
println!(Enter another index: );
}
}
The task spawned for each entered number provides a boundary in case of
a failure. So if the user enters an invalid index (or something that
can't be interpreted as an int) only the task dies, prints its error
message and the outer loop just continues.
Removing the boundary checks would change the API just like removing the
exception from the C++ code. Suddenly you don't have the (rather
simplistic) error handling that just kills the task anymore, but can end
up with sefaults or memory corruption (if this was writing to memory).
The proposed switch would therefore possibly turn previously _handled_
errors into unhandled ones. I think that's (at least in part) what
Daniel meant when he said that you'd effectively create a new language
dialect.
Björn
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
2014-03-29 21:53 GMT+09:00 Zoltán Tóth zo1...@gmail.com: Use 'unsafe' everywhere? Yes, using the `unsafe fn` in place of `fn` everywhere should be sufficient. Actually it is not very hard to do so (before writing this I have experimented with my own project for this strategy and it only had a minor impact, but your mileage may vary) and if you want to follow this path further you can build an alternative standard library for unsafe uses *without changing the language itself*. 2014-03-29 21:53 GMT+09:00 Zoltán Tóth zo1...@gmail.com: Devs, please explain how such option could decrease the safety of the language. As it would be just that, an option, an opt-in one. Out-of-bound conditions are unsafe because they are well-known causes of serious bugs (I seriously recommend the RISKS Digest for this matter). We are well aware that there are other major causes of bugs (e.g. interger overflow), but out-of-bound conditions are particularly severe and deserves a solution. I would really appreciate better solutions for the bounds check, but disabling the bounds check without an alternative measure will considerably hurt the main goal of Rust. -- -- Kang Seonghoon | Software Engineer, iPlateia Inc. | http://mearie.org/ -- Opinions expressed in this email do not necessarily represent the views of my employer. -- ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
Thank Björn Steinbrink for your example. Though Daniel already mentioned the key [the difference between the runtime and logic errors] earlier many times, I only now understood it from the example. Sorry ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
Might it be useful to turn this the other way up, and introduce an option to *add* bounds checks to unsafe indexing when debugging? It seems like removing that undefined behaviour would make debugging of unsafe code easier, like the optional bounds checks for unsafe programming languages that people are referring to. (This may be silly, unnecessary, already done, or infeasible, or I may be missing something obvious---I have yet to reach my intended level of familiarity with rust. But it seemed like a question worth asking). David ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
This is essentially what ASan already does, AFAIK. I would like ASan support for Rust someday, as unsafe code can still benefit from it (although not to the degree that C code does, obviously). Patrick On March 29, 2014 6:44:08 PM PDT, David Morris davidrowlandmor...@gmail.com wrote: Might it be useful to turn this the other way up, and introduce an option to *add* bounds checks to unsafe indexing when debugging? It seems like removing that undefined behaviour would make debugging of unsafe code easier, like the optional bounds checks for unsafe programming languages that people are referring to. (This may be silly, unnecessary, already done, or infeasible, or I may be missing something obvious---I have yet to reach my intended level of familiarity with rust. But it seemed like a question worth asking). David ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 28/03/14 03:48, Daniel Micay wrote: On 27/03/14 11:04 PM, Tommi Tissari wrote: Case by case is all fine and good. But you're trying argue what a programmer *should* do if he knew what was good for him. Rust doesn't view the programmer as an infallible, trusted entity. Actually, I believe it does, with this policy. The infallible programmer it imagines, however, is not the developer; true. It is worse: this policy currently assumes that the policy makers / compiler creators themselves are infallible; that language users (even language users of the future, who may have much more knowledge and experience than anyone participating in this discussion today) are idiots who don't know what they're doing, or at least, will never know more than the language creators. This is NOT trusting the tireless work of a compiler: it's being arrogant, and trusting yourself more than others, whose abilities and circumstances you do not even know. Worse: it is failing to learn from history. The very reason that C / C++ succeeded is that they don't force things on developers: they assist, give options. They choose defaults, yes, and make things easier, yes; but they always provide the option to move out of the way, when it turns out that those defaults are actually making things harder. The very reason that many other languages fail is that they failed to provide the ability to adapt to changing needs. Forcing bounds checking on everyone is really not that different from forcing garbage collection on everyone: it may seem like a good idea to some --- even many --- but to others, it is overly limiting. As another point of consideration, you should probably bear in mind that Rust's boundary checking IS very limited, and people may actually want to override it because they have something better. QA, as mentioned before, can do it better (once, at the right time, on the right variables, only for the right values of those variables, before each release, and only for the code touched in that release), but so might a separate static analysis tool, for another instance. There seem to be a few people saying that providing an option to disable boundary checks would constitute an ABI change. If so, that's fine: maybe it makes it more trouble than it's worth to do. Maybe that's scary. OR, maybe the fact that it requires an ABI change is an indication of a deeper design flaw. Maybe that's even scarier. But, one way or another, these knee-jerk reactions to a simple request to disable a feature do smack of fear. I would suggest that people face that fear, and acknowledge the real problem, rather than telling people they shouldn't be asking for the freedom to build a program as they see fit. -- Lee ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 28 Mar 2014, at 05:48, Daniel Micay danielmi...@gmail.com wrote:
I don't know about those other dialects.
You're proposing introducing new dialect of Rust.
In Crust, code generating a failure on out-of-bounds will now cause
silent memory corruption. Crust will do away with safety boundaries
completely by making `unsafe` and lifetimes a no-op in order to be a
true superset of Rust.
In Frust, indexing slices is considered an unsafe operation. Very little
existing Rust code will compile under Frust, and some previously safe
checked indexing inside existing `unsafe` blocks will cause silent
memory corruption.
I'm not sure which of these dialects you're proposing, but either one
would require a new set of buildbots to run the tests again. Both the
Crust and Frust languages would require many changes to the
documentation and code of the Rust libraries too.
I'm proposing Frust. The flag would make indexing unsafe and change all
functions that use indexing to unsafe and all functions that call those
functions unsafe etc. Inside main and tests it would wrap unsafe blocks around
all calls to those functions which it just made implicitly unsafe.
In D, if you put the label safe in the beginning of each module and compile
it with safe flag (and not with noboundscheck flag), then it is memory safe
barring compiler bugs. It doesn't allow you to use pointer arithmetic or
unsafe casts or call unsafe functions, but that's hardly what I'd call a
*crippled* subset of the language.
D doesn't even let you use ranges (iterators) in safe code. There are
barely any safe functions here, and that's true of most of the standard
library:
http://dlang.org/phobos/std_range.html
This is incorrect. All those range based functions (or majority of them... I'm
not sure) are safe if the range(s) you pass to them is safe. That's why those
range functions can't guarantee safety as part of their signature. For example,
look at the following D code, where I'm using range based functions on a range
that's memory safe in a code labeled as safe:
import std.algorithm;
import std.range;
import std.stdio;
@safe: // Labels everything memory-safe
@trusted void show(T)(T a)
{
write(a, );
}
void main()
{
auto array = [1, 2, 3, 4, 5];
auto range = array[].retro
.map!(a = a * a)
.stride(2)
.cycle
.take(6);
foreach (elem; range)
{
show(elem); // prints 25 9 1 25 9 1
}
}
If you want D, then please go ahead and use D.
Not constructive.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 28/03/14 22:04, Lee Braiden wrote: On 28/03/14 03:48, Daniel Micay wrote: On 27/03/14 11:04 PM, Tommi Tissari wrote: Case by case is all fine and good. But you're trying argue what a programmer *should* do if he knew what was good for him. Rust doesn't view the programmer as an infallible, trusted entity. Actually, I believe it does, with this policy. The infallible programmer it imagines, however, is not the developer; true. It is worse: this policy currently assumes that the policy makers / compiler creators themselves are infallible; that language users (even language users of the future, who may have much more knowledge and experience than anyone participating in this discussion today) are idiots who don't know what they're doing, or at least, will never know more than the language creators. This is NOT trusting the tireless work of a compiler: it's being arrogant, and trusting yourself more than others, whose abilities and circumstances you do not even know. At no point do the compiler writers assume they themselves are infallible; if they did, the compiler and stdlib could just be written with unsafe everywhere, to avoid having to satisfy rustc, which can be annoyingly picky. You'll notice that this is not the case, and reviewers strongly discourage adding large amounts of `unsafe`, preferring completely safe code, or, if that's not possible, the unsafety wrapped into self-contained segments, to make auditing them for correctness easier. In fact, a large motivation for working on Rust is because the developers know how fallible they are. A lot of work has gone, and is going, into making the compiler and libraries safe and correct. (Of course, getting a completely verified-correct compiler is really, really hard work, and even the proof of correctness of the type system is incomplete, but is currently being worked on.) In any case, those writing the compiler are likely to be the ones with the best knowledge of Rust, and, in particular, the best knowledge of how to write correct unsafe/low-level code: e.g. how to avoid inducing undefined behaviour, and how to maintain the various invariants that exist. I think it's reasonable to assume that most other people using Rust will not have this in depth knowledge. Personally, I would prefer to put more trust in the experienced users. (Experience in writing safe Rust code is less relevant here, since, assuming the proof works smoothly/we adjust the language to make it work, it will be impossible to write vulnerable code without `unsafe`.) Worse: it is failing to learn from history. The very reason that C / C++ succeeded is that they don't force things on developers: they assist, give options. They choose defaults, yes, and make things easier, yes; but they always provide the option to move out of the way, when it turns out that those defaults are actually making things harder. The very reason that many other languages fail is that they failed to provide the ability to adapt to changing needs. Forcing bounds checking on everyone is really not that different from forcing garbage collection on everyone: it may seem like a good idea to some --- even many --- but to others, it is overly limiting. Rust explicitly gives options too, and definitely does *not* force bounds checking on everyone: the `unsafe` escape hatch allows someone to choose to forgo bounds checking when it has a noticeable effect on performance, and there's no safe substitute (i.e. non-sequential vector accesses in a tight loop). Huon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 28/03/14 07:04 AM, Lee Braiden wrote:
On 28/03/14 03:48, Daniel Micay wrote:
On 27/03/14 11:04 PM, Tommi Tissari wrote:
Case by case is all fine and good. But you're trying argue what a
programmer *should* do if he knew what was good for him.
Rust doesn't view the programmer as an infallible, trusted entity.
Actually, I believe it does, with this policy. The infallible
programmer it imagines, however, is not the developer; true. It is
worse: this policy currently assumes that the policy makers / compiler
creators themselves are infallible; that language users (even language
users of the future, who may have much more knowledge and experience
than anyone participating in this discussion today) are idiots who don't
know what they're doing, or at least, will never know more than the
language creators. This is NOT trusting the tireless work of a
compiler: it's being arrogant, and trusting yourself more than others,
whose abilities and circumstances you do not even know.
Rust provides unchecked indexing. The compiler/library developers have
to use `unsafe {}` in order to make use of it too. They're not held to a
different standard. You may not be aware that Rust is written in Rust,
but it's written in over 200k lines of it. The Rust developers are by
far the most prolific users of the language, and are very aware of what
it's like to write code in the language.
I certainly do not see myself as an idiot, if that's what you're trying
to imply. In fact I think I'm quite clever. However, I'm definitely not
capable of writing bug-free code all the time. You can call us arrogant
or question our motives, but true arrogance is thinking that you can
write bug-free code at a non-trivial scale.
The Rust developers strive to keep the amount of `unsafe` code at a
minimum and only use it when it's proven to result in tangible
performance wins. This is also how things are done in Servo, and it is
intended to be how the language is used. That's why it puts so much work
into drawing safety boundaries.
Rust is designed first and foremost as a memory safe language, and
that's not going to change. Safety is why most of Rust's type exists,
and Rust programmers are free to use `unsafe` as often as they feel is
necessary to subvert the type system when they know better. You have
every freedom to fork the language if you want to take it in a different
direction.
Worse: it is failing to learn from history. The very reason that C /
C++ succeeded is that they don't force things on developers: they
assist, give options. They choose defaults, yes, and make things
easier, yes; but they always provide the option to move out of the way,
when it turns out that those defaults are actually making things
harder. The very reason that many other languages fail is that they
failed to provide the ability to adapt to changing needs.
The 'default' (via []) is checked indexing, and unchecked indexing is
available. In C++, the default is unchecked indexing (via []) and
checked indexing is available on std::array and std::vector via `at`.
There's no switch to flip what [] does for those types. There's no
configuration of the default in C or C++ - that's nonsense.
Rust provides `unsafe` for when you need the compiler to get out of the
way. Claiming that the option is not provided is an outright falsehood.
Forcing bounds checking on everyone is really not that different from
forcing garbage collection on everyone: it may seem like a good idea to
some --- even many --- but to others, it is overly limiting.
It's not forced on you. You are free to use the unchecked indexing
whenever you think it is appropriate. It's not about whether it is a
good idea or a bad idea - in some cases, bounds checking is *necessary*
and in others you can prove to yourself that it is not necessary. In
those cases where it is not necessary, Rust allows you to avoid bounds
checking. You are free to do *all* of your indexing via unchecked
indexing if you trust yourself (and anyone else who will touch the code)
to write bug-free code all the time.
In fact, why not use C++? You're not going to want sum types if you can
just use unions without the dirty compiler getting in your way. You're
not going to want checked type bounds on generics - type classes are
clearly just arrogance on the part of developers, users can be expected
to read the requirements of a generic function and never write code
generating errors from the implementation details.
Lifetimes serve no purpose other than to prevent the programmer from
doing stuff, and are *entirely* stripped out before code generation. Do
you want to override/disable borrow checking and freezing too?
There's also the exhaustiveness check in match and let expressions.
There's the imperfect flow control analysis used to guarantee that
there's a return before the end of a function. There's a dynamic check
on integer division for a zero divisor, and INT_MIN / -1 needs to be
checked for too with
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 28 Mar 2014, at 05:56, Patrick Walton pcwal...@mozilla.com wrote: I think that Rust should give you the ability to opt out of safety, but on a per-operation basis. Having it as a compiler option is too much of a sledgehammer: often you want some non-performance-critical bounds to be checked in the name of safety, while you want some bounds checks to be turned off. One other argument I can give for a sledgehammer feature like this is that it can be used as a marketing tool against people who are worried about performance. You can say to those people: Look, if, at the end of the day, you decide that you'd rather take raw speed over safety, then there's this compiler flag you can use to disable all runtime memory safety checking in your code and get performance on par with C++. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 28/03/14 08:25 AM, Tommi wrote: On 28 Mar 2014, at 05:56, Patrick Walton pcwal...@mozilla.com wrote: I think that Rust should give you the ability to opt out of safety, but on a per-operation basis. Having it as a compiler option is too much of a sledgehammer: often you want some non-performance-critical bounds to be checked in the name of safety, while you want some bounds checks to be turned off. One other argument I can give for a sledgehammer feature like this is that it can be used as a marketing tool against people who are worried about performance. You can say to those people: Look, if, at the end of the day, you decide that you'd rather take raw speed over safety, then there's this compiler flag you can use to disable all runtime memory safety checking in your code and get performance on par with C++. It's called `unsafe`. There's a whole keyword reserved for it. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 3/28/14 5:25 AM, Tommi wrote: On 28 Mar 2014, at 05:56, Patrick Walton pcwal...@mozilla.com wrote: I think that Rust should give you the ability to opt out of safety, but on a per-operation basis. Having it as a compiler option is too much of a sledgehammer: often you want some non-performance-critical bounds to be checked in the name of safety, while you want some bounds checks to be turned off. One other argument I can give for a sledgehammer feature like this is that it can be used as a marketing tool against people who are worried about performance. You can say to those people: Look, if, at the end of the day, you decide that you'd rather take raw speed over safety, then there's this compiler flag you can use to disable all runtime memory safety checking in your code and get performance on par with C++. Well, people who would be persuaded by that would probably also want the borrow check off, and might want the mutability restrictions off too. It just wouldn't be the same language. It might be interesting to try to design a systems language with no regard for safety and the other modern/functional programming goodies that Rust has (concepts/traits, algebraic data types, a module system), but Rust just isn't that language. Safety-by-default is core to its design. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
We don't WANT that though. Haven't you been reading? If we need that flag to perform as well as C++, we'll have failed in our mission. We don't just want to make a safe language: we want to make one safe, fast, and concurrent. Also, as Daniel pointed out, the stdlib already relies heavily on safety guarantees, and breaking those would mean you wouldn't be able to use a large percentage of the stdlib functions, and be stuck writing your own. On Mar 28, 2014 7:25 AM, Tommi rusty.ga...@icloud.com wrote: On 28 Mar 2014, at 05:56, Patrick Walton pcwal...@mozilla.com wrote: I think that Rust should give you the ability to opt out of safety, but on a per-operation basis. Having it as a compiler option is too much of a sledgehammer: often you want some non-performance-critical bounds to be checked in the name of safety, while you want some bounds checks to be turned off. One other argument I can give for a sledgehammer feature like this is that it can be used as a marketing tool against people who are worried about performance. You can say to those people: Look, if, at the end of the day, you decide that you'd rather take raw speed over safety, then there's this compiler flag you can use to disable all runtime memory safety checking in your code and get performance on par with C++. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
A good plus for rust here is that in general, the idiomatic way to access
arrays in a loop doesn't use bounds checking. For example, to write a dot
product in c++ you'd do this:
double dot(const double* x, const double* y, int len) {
double result = 0.0;
for(int i = 0; i len; ++i)
result += x[i]*y[i];
return result;
}
This isn't very safe, and you don't pay for bounds checks. Fair enough. Now
in rust:
fn dot(x: Vecdouble, y: Vecdouble) - double {
x.iter().zip(y.iter()).fold(0.0, |k, (x, y)| k + x*y)
}
That's safe, and doesn't bounds check. Potential slowness of the closure
aside, this should be just as efficient. In general, your loops won't
directly index arrays.
- Clark
On Fri, Mar 28, 2014 at 8:31 AM, Patrick Walton pcwal...@mozilla.comwrote:
On 3/28/14 5:25 AM, Tommi wrote:
On 28 Mar 2014, at 05:56, Patrick Walton pcwal...@mozilla.com wrote:
I think that Rust should give you the ability to opt out of safety, but
on a per-operation basis. Having it as a compiler option is too much of a
sledgehammer: often you want some non-performance-critical bounds to be
checked in the name of safety, while you want some bounds checks to be
turned off.
One other argument I can give for a sledgehammer feature like this
is that it can be used as a marketing tool against people who are
worried about performance. You can say to those people: Look, if, at
the end of the day, you decide that you'd rather take raw speed over
safety, then there's this compiler flag you can use to disable all
runtime memory safety checking in your code and get performance on
par with C++.
Well, people who would be persuaded by that would probably also want the
borrow check off, and might want the mutability restrictions off too. It
just wouldn't be the same language.
It might be interesting to try to design a systems language with no regard
for safety and the other modern/functional programming goodies that Rust
has (concepts/traits, algebraic data types, a module system), but Rust just
isn't that language. Safety-by-default is core to its design.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Clark.
Key ID : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 28/03/14 07:44 AM, Tommi wrote: This is incorrect. All those range based functions (or majority of them... I'm not sure) are safe if the range(s) you pass to them is safe. That's why those range functions can't guarantee safety as part of their signature. For example, look at the following D code, where I'm using range based functions on a range that's memory safe in a code labeled as safe: So if you make a range, store it and then resize a container, it remains safe? signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 28 Mar 2014, at 14:27, Daniel Micay danielmi...@gmail.com wrote: On 28/03/14 08:25 AM, Tommi wrote: On 28 Mar 2014, at 05:56, Patrick Walton pcwal...@mozilla.com wrote: I think that Rust should give you the ability to opt out of safety, but on a per-operation basis. Having it as a compiler option is too much of a sledgehammer: often you want some non-performance-critical bounds to be checked in the name of safety, while you want some bounds checks to be turned off. One other argument I can give for a sledgehammer feature like this is that it can be used as a marketing tool against people who are worried about performance. You can say to those people: Look, if, at the end of the day, you decide that you'd rather take raw speed over safety, then there's this compiler flag you can use to disable all runtime memory safety checking in your code and get performance on par with C++. It's called `unsafe`. There's a whole keyword reserved for it. From a marketing standpoint, I don't think that the following sounds very appealing: Look, if, at the end of the day, you'd rather choose raw speed over safety, then you can go over all the hundreds of thousands of lines of code you have and change everything to their unsafe, unchecked variants. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 28/03/14 23:49, Tommi wrote: On 28 Mar 2014, at 14:27, Daniel Micay danielmi...@gmail.com wrote: On 28/03/14 08:25 AM, Tommi wrote: On 28 Mar 2014, at 05:56, Patrick Walton pcwal...@mozilla.com wrote: I think that Rust should give you the ability to opt out of safety, but on a per-operation basis. Having it as a compiler option is too much of a sledgehammer: often you want some non-performance-critical bounds to be checked in the name of safety, while you want some bounds checks to be turned off. One other argument I can give for a sledgehammer feature like this is that it can be used as a marketing tool against people who are worried about performance. You can say to those people: Look, if, at the end of the day, you decide that you'd rather take raw speed over safety, then there's this compiler flag you can use to disable all runtime memory safety checking in your code and get performance on par with C++. It's called `unsafe`. There's a whole keyword reserved for it. From a marketing standpoint, I don't think that the following sounds very appealing: Look, if, at the end of the day, you'd rather choose raw speed over safety, then you can go over all the hundreds of thousands of lines of code you have and change everything to their unsafe, unchecked variants. Flip it around: Look, if, at the end of the day, you'd rather choose safety over raw speed, then you can go over all the hundreds of thousands of lines of code you have and change everything to their safe, checked variants. Getting code correct is the first step to getting it fast: it doesn't matter how fast a program runs if it's just doing the wrong thing really quickly (e.g. exposing the users computer to hijacking). Most code isn't in a tight inner loop, and so the piece-of-mind of it being safe by default is worth the effort one has to put in to profile and examine the very core logic that gets called millions of times. It's much harder to use automated tools to find all of the memory safety bugs. And anyway, as Daniel and Patrick say, if you don't need the utmost safety, then Rust isn't the language you're looking for: things like C++ work well in the speed department, at the cost of safety. Huon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
If your hotspot is spread across thousands and thousands of lines of code, you have made major architectural mistakes. On 28 Mar 2014, at 12:49, Tommi rusty.ga...@icloud.com wrote: On 28 Mar 2014, at 14:27, Daniel Micay danielmi...@gmail.com wrote: On 28/03/14 08:25 AM, Tommi wrote: On 28 Mar 2014, at 05:56, Patrick Walton pcwal...@mozilla.com wrote: I think that Rust should give you the ability to opt out of safety, but on a per-operation basis. Having it as a compiler option is too much of a sledgehammer: often you want some non-performance-critical bounds to be checked in the name of safety, while you want some bounds checks to be turned off. One other argument I can give for a sledgehammer feature like this is that it can be used as a marketing tool against people who are worried about performance. You can say to those people: Look, if, at the end of the day, you decide that you'd rather take raw speed over safety, then there's this compiler flag you can use to disable all runtime memory safety checking in your code and get performance on par with C++. It's called `unsafe`. There's a whole keyword reserved for it. From a marketing standpoint, I don't think that the following sounds very appealing: Look, if, at the end of the day, you'd rather choose raw speed over safety, then you can go over all the hundreds of thousands of lines of code you have and change everything to their unsafe, unchecked variants. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 28 Mar 2014, at 15:01, Huon Wilson dbau...@gmail.com wrote: [..] And anyway, as Daniel and Patrick say, if you don't need the utmost safety, then Rust isn't the language you're looking for: things like C++ work well in the speed department, at the cost of safety Yes, it seems that Rust isn't the language for those people. But what I'm saying is that Rust *could* be the language for those people *too*, if it wanted to. Even those people who don't need the utmost safety might take it if it's deemed not too big of a hindrance on performance. But it's probably impossible to determine beforehand whether the performance hit caused by safety will be within acceptable limits or not. Which is why those people need to be able to make that decision after the (safe) code has been written and make the switch quickly to raw performance with a compiler flag. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
It just seems that all arguments have been made 5+ times by both sides. I would agree that mailing list discussions that start going in circles become no longer appropriate for a mailing list. On Fri, Mar 28, 2014 at 7:48 AM, Tommi rusty.ga...@icloud.com wrote: On 28 Mar 2014, at 15:43, Matthew Frazier leafstormr...@gmail.com wrote: I would just like to interject that this conversation has been blowing my inbox up all morning and seems to be going absolutely nowhere. That's a good argument against using mailing lists for this kind of a purpose. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
I would just like to interject that this conversation has been blowing my inbox up all morning and seems to be going absolutely nowhere. The people on both sides of this issue have stated their arguments exhaustively, and I neither believe that the Rust developers would ever introduce a flag that disables such a wide-reaching safety features, nor that the advocates of such a flag will understand why anytime this month. I would therefore recommend that all participants cease sending messages to this thread, so that other discussions can continue in peace. Thanks, Matthew Frazier On Mar 28, 2014 9:35 AM, Tommi rusty.ga...@icloud.com wrote: On 28 Mar 2014, at 15:01, Huon Wilson dbau...@gmail.com wrote: [..] And anyway, as Daniel and Patrick say, if you don't need the utmost safety, then Rust isn't the language you're looking for: things like C++ work well in the speed department, at the cost of safety Yes, it seems that Rust isn't the language for those people. But what I'm saying is that Rust *could* be the language for those people *too*, if it wanted to. Even those people who don't need the utmost safety might take it if it's deemed not too big of a hindrance on performance. But it's probably impossible to determine beforehand whether the performance hit caused by safety will be within acceptable limits or not. Which is why those people need to be able to make that decision after the (safe) code has been written and make the switch quickly to raw performance with a compiler flag. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 28/03/14 15:31, Sanghyeon Seo wrote: To defend rustc's honor: rustc has no such design issues. That's my favourite part of this whole thread. Really. :D -- Lee ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 28 Mar 2014, at 17:46, Erick Tryzelaar erick.tryzel...@gmail.com wrote: Disagreement is fine [..] I would think that to be an axiom which didn't need to be mentioned. What I think this whole discussion boils down to, is orthodoxy vs. pragmatism. The pragmatic think that wiggle room is always good and that it's good to allow programmers to compile their code into a fast but unsafe beast of a program if they so choose to. The dogmatic wouldn't allow that because it contradicts some over-arching design principle. The actual issue we discussed here really just boils down to taste. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 28 Mar 2014, at 14:47, Daniel Micay danielmi...@gmail.com wrote: On 28/03/14 07:44 AM, Tommi wrote: This is incorrect. All those range based functions (or majority of them... I'm not sure) are safe if the range(s) you pass to them is safe. That's why those range functions can't guarantee safety as part of their signature. For example, look at the following D code, where I'm using range based functions on a range that's memory safe in a code labeled as safe: So if you make a range, store it and then resize a container, it remains safe? That will most likely be a bug in your code, but yes, that will be memory safe given that all the functions involved in this are safe (or they can be @trusted given they don't break their promise of being memory safe). Obviously all of this assumes that you haven't disabled the garbage collector (in which case all bets would be off). ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 28 Mar 2014, at 15:43, Matthew Frazier leafstormr...@gmail.com wrote: I would just like to interject that this conversation has been blowing my inbox up all morning and seems to be going absolutely nowhere. That's a good argument against using mailing lists for this kind of a purpose. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
Do not close this thread. This is actually the most exciting one currently. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On Thu, Mar 27, 2014 at 1:17 PM, Steve Klabnik st...@steveklabnik.comwrote: Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks It seems like, prior to even proposing such a feature, you should at least make the effort to disable the existing bounds checks in the language, run benchmarks, and actually compare the performance impact. This is the minimum due diligence I would suggest when suggesting a modification to a language which is specifically designed for memory safety. Anything less is, at best, premature optimization. Will removing the bounds checks improve performance? Who knows, probably, but without numbers, it's a change that's hard to gauge. It is, however, quite easy to gauge the impact on the memory safety of the language: it would decrease it, and Rust already provides unsafe blocks if you need better performance. So it seems silly to suggest modifications to what is otherwise the safe subset of the language without at least making a rudimentary measurement. You are suggesting a change to the safe subset of the language, based on handwavy premature optimization. Based on that, I must say I abjectly reject your ideas. I suggest you better formalize them, measure, and present a more concrete plan which is rooted in empirical measurement, not hey I don't know what the hell I'm talking about but think this thing is slow -- Tony Arcieri ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 28/03/14 09:52 PM, Tony Arcieri wrote: On Thu, Mar 27, 2014 at 1:17 PM, Steve Klabnik st...@steveklabnik.com mailto:st...@steveklabnik.com wrote: Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks It seems like, prior to even proposing such a feature, you should at least make the effort to disable the existing bounds checks in the language, run benchmarks, and actually compare the performance impact. This is the minimum due diligence I would suggest when suggesting a modification to a language which is specifically designed for memory safety. Anything less is, at best, premature optimization. Will removing the bounds checks improve performance? Who knows, probably, but without numbers, it's a change that's hard to gauge. It is, however, quite easy to gauge the impact on the memory safety of the language: it would decrease it, and Rust already provides unsafe blocks if you need better performance. So it seems silly to suggest modifications to what is otherwise the safe subset of the language without at least making a rudimentary measurement. You are suggesting a change to the safe subset of the language, based on handwavy premature optimization. Based on that, I must say I abjectly reject your ideas. I suggest you better formalize them, measure, and present a more concrete plan which is rooted in empirical measurement, not hey I don't know what the hell I'm talking about but think this thing is slow -- Tony Arcieri You can already use unchecked indexing in any case where there's a performance issue so I don't really understand what the fuss is about. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On Fri, Mar 28, 2014 at 6:55 PM, Daniel Micay danielmi...@gmail.com wrote: You can already use unchecked indexing in any case where there's a performance issue so I don't really understand what the fuss is about. Confirm. This entire thread seems like much ado about nothing. -- Tony Arcieri ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On Fri, Mar 28, 2014 at 8:14 AM, Daniel Micay danielmi...@gmail.com wrote: Lifetimes serve no purpose other than to prevent the programmer from doing stuff, and are *entirely* stripped out before code generation. Do you want to override/disable borrow checking and freezing too? There's also the exhaustiveness check in match and let expressions. There's the imperfect flow control analysis used to guarantee that there's a return before the end of a function. There's a dynamic check on integer division for a zero divisor, and INT_MIN / -1 needs to be checked for too with signed integer division. There's the dynamic borrow checking performed on RefCell, which has to be used if you want mutability combined with shared ownership of a non-plain old data type in RcT. This is unfair. You're mixing up static checks such as exhaustiveness, freezing, and lifetimes, which have no performance impact (or at least, the performance impact caused by their limitations would be mitigated only by fundamentally rearchitecting the user code, not flipping a check off), with dynamic checks such as array bounds, RefCell, and division, which have an impact and can be flipped off. (I'm not disagreeing with any other arguments, although I do think it would be interesting to try it and get actual numbers on its effect on rustc and Servo's performance.) ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 29/03/14 12:10 AM, comex wrote: On Fri, Mar 28, 2014 at 8:14 AM, Daniel Micay danielmi...@gmail.com wrote: Lifetimes serve no purpose other than to prevent the programmer from doing stuff, and are *entirely* stripped out before code generation. Do you want to override/disable borrow checking and freezing too? There's also the exhaustiveness check in match and let expressions. There's the imperfect flow control analysis used to guarantee that there's a return before the end of a function. There's a dynamic check on integer division for a zero divisor, and INT_MIN / -1 needs to be checked for too with signed integer division. There's the dynamic borrow checking performed on RefCell, which has to be used if you want mutability combined with shared ownership of a non-plain old data type in RcT. This is unfair. You're mixing up static checks such as exhaustiveness, freezing, and lifetimes, which have no performance impact (or at least, the performance impact caused by their limitations would be mitigated only by fundamentally rearchitecting the user code, not flipping a check off), with dynamic checks such as array bounds, RefCell, and division, which have an impact and can be flipped off. These do often have a performance impact despite being static checks. The borrow checker forbids many valid patterns, and forces either a less efficient solution or using `unsafe`. This is no different from how you are forced to choose between safe indexingand unsafe indexing. There seems to be a serious misunderstanding about bounds checking in Rust in this thread. The bounds check is *not* a dynamic check inserted to make sure that the code is valid. It is a normal runtime check, like checking if a string is valid when parsing it into an integer. There is a semantic difference between that and assuming the string is valid. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On Sat, Mar 29, 2014 at 12:19 AM, Daniel Micay danielmi...@gmail.com wrote: This is unfair. You're mixing up static checks such as exhaustiveness, freezing, and lifetimes, which have no performance impact (or at least, the performance impact caused by their limitations would be mitigated only by fundamentally rearchitecting the user code, not flipping a check off), with dynamic checks such as array bounds, RefCell, and division, which have an impact and can be flipped off. These do often have a performance impact despite being static checks. The borrow checker forbids many valid patterns, and forces either a less efficient solution or using `unsafe`. This is no different from how you are forced to choose between safe indexingand unsafe indexing. As I said, if you want to use the more efficient solution in that case, you have to rewrite the code to be unsafe-only anyway, so there is no (well, very little) downside to using special syntax rather than making the existing syntax do something different. With dynamic checks, it is not usually necessary to rewrite. seems to be a serious misunderstanding about bounds checking in Rust in this thread. The bounds check is *not* a dynamic check inserted to make sure that the code is valid. It is a normal runtime check, like checking if a string is valid when parsing it into an integer. There is a semantic difference between that and assuming the string is valid. This is one of the arguments I was not disagreeing with. But from the pragmatic perspective of getting numbers for Science, I doubt any actual Rust code depends on this distinction. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 29/03/14 12:36 AM, comex wrote: On Sat, Mar 29, 2014 at 12:19 AM, Daniel Micay danielmi...@gmail.com wrote: This is unfair. You're mixing up static checks such as exhaustiveness, freezing, and lifetimes, which have no performance impact (or at least, the performance impact caused by their limitations would be mitigated only by fundamentally rearchitecting the user code, not flipping a check off), with dynamic checks such as array bounds, RefCell, and division, which have an impact and can be flipped off. These do often have a performance impact despite being static checks. The borrow checker forbids many valid patterns, and forces either a less efficient solution or using `unsafe`. This is no different from how you are forced to choose between safe indexingand unsafe indexing. As I said, if you want to use the more efficient solution in that case, you have to rewrite the code to be unsafe-only anyway, so there is no (well, very little) downside to using special syntax rather than making the existing syntax do something different. With dynamic checks, it is not usually necessary to rewrite. A rewrite is usually going to be required, because the code was not written with unsafe indexing in mind. Since sequential access is covered well by iterators, most indexing in Rust is using dynamically generated indexes which are not usually carefully checked. The failure already handles checking, so it would be redundant to do it manually except to report a higher-level error, but the libraries and compiler don't do much of that. This is one of the arguments I was not disagreeing with. But from the pragmatic perspective of getting numbers for Science, I doubt any actual Rust code depends on this distinction. A lot of code in the compiler simply leaves out error checking and relies on getting an ICE from the failure. It would take a long time to translate everything into proper error messages. The standard library also *often* assumes preconditions are true and relies on bounds checking to catch any errors. This is the standard way to write code, so it's not correct to assume that a bounds check failure is a logic error made by the programmer who wrote the code. They are just normal runtime failures. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On Sat, Mar 29, 2014 at 12:41 AM, Daniel Micay danielmi...@gmail.com wrote: A lot of code in the compiler simply leaves out error checking and relies on getting an ICE from the failure. It would take a long time to translate everything into proper error messages. Well, a compiler should not intentionally ICE in most situations, that has to happen anyway :) But okay, maybe I am wrong about actual Rust code as it currently exists. Still, I assume that this isn't a normal part of compilation, so I might benchmark it anyway to see whether there actually is any measurable difference or not. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 27 Mar 2014, at 22:17, Steve Klabnik st...@steveklabnik.com wrote: Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks (which people are bound to make with no bounds checking in C++ at least) be more apples-to-apples comparisons. Also, knowing there's a flag in case you need one would put performance-critical people's mind A flag that removes safety is pretty antithical to the goals of the language, IMHO. Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
I think your hypothetical situation of saving millions by disabling bounds checks is absurd: To save $10 per machine, assuming $0.20 per kilowatt-hour, and saving 50 nanojoules per bounds check, you'd need to be avoiding about 10^14 check. That's equivalent to avoiding 1 million bounds checks every second. Even if you had hundreds of CPU cores running at full processing power, I would posit that there are bigger problems, and you're probably spending way more power on cache misses or something. On Thu, Mar 27, 2014 at 1:42 PM, Tommi rusty.ga...@icloud.com wrote: On 27 Mar 2014, at 22:17, Steve Klabnik st...@steveklabnik.com wrote: Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks (which people are bound to make with no bounds checking in C++ at least) be more apples-to-apples comparisons. Also, knowing there's a flag in case you need one would put performance-critical people's mind A flag that removes safety is pretty antithical to the goals of the language, IMHO. Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
I think the point is that the compiler should not be forcing people to do things, but enabling people to do things, with sensible defaults. Personally, whilst I would advocate MORE bounds checking in rust for debugging / prototyping purposes, I don't think bounds checking is even ideal. It's a useful tool WHILST prototyping software, but if you really want to ensure quality, you do a full QA process, examining all boundary and corner cases closely. When that's been done, then bounds checks become both unnecessary, and inefficient. No, not massively unnecessary or inefficient, but unnecessary and inefficient, all the same. -- Lee On 27/03/14 23:09, Matthew McPherrin wrote: I think your hypothetical situation of saving millions by disabling bounds checks is absurd: To save $10 per machine, assuming $0.20 per kilowatt-hour, and saving 50 nanojoules per bounds check, you'd need to be avoiding about 10^14 check. That's equivalent to avoiding 1 million bounds checks every second. Even if you had hundreds of CPU cores running at full processing power, I would posit that there are bigger problems, and you're probably spending way more power on cache misses or something. On Thu, Mar 27, 2014 at 1:42 PM, Tommi rusty.ga...@icloud.com wrote: On 27 Mar 2014, at 22:17, Steve Klabnik st...@steveklabnik.com wrote: Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks (which people are bound to make with no bounds checking in C++ at least) be more apples-to-apples comparisons. Also, knowing there's a flag in case you need one would put performance-critical people's mind A flag that removes safety is pretty antithical to the goals of the language, IMHO. Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
Alternatively, in this future where people are deploying Rust applications to hundreds of thousands of servers, we could be using Intel's Memory Protection Extensions for much cheaper bounds checking etc. Which surely other applications will be using once bounds checks are nearly free. Rust will still have the advantage of only needing bounds checking for vectors and not *every* pointer like they are integrating into GCC. On Thu, Mar 27, 2014 at 4:42 PM, Tommi rusty.ga...@icloud.com wrote: On 27 Mar 2014, at 22:17, Steve Klabnik st...@steveklabnik.com wrote: Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks (which people are bound to make with no bounds checking in C++ at least) be more apples-to-apples comparisons. Also, knowing there's a flag in case you need one would put performance-critical people's mind A flag that removes safety is pretty antithical to the goals of the language, IMHO. Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
It's not about debugging, it's about memory safety. It'd be ridiculous to disable bounds checking just because you've done QA. How many security exploits are over- or under-flows? On Thu, Mar 27, 2014 at 7:16 PM, Lee Braiden leebr...@gmail.com wrote: I think the point is that the compiler should not be forcing people to do things, but enabling people to do things, with sensible defaults. Personally, whilst I would advocate MORE bounds checking in rust for debugging / prototyping purposes, I don't think bounds checking is even ideal. It's a useful tool WHILST prototyping software, but if you really want to ensure quality, you do a full QA process, examining all boundary and corner cases closely. When that's been done, then bounds checks become both unnecessary, and inefficient. No, not massively unnecessary or inefficient, but unnecessary and inefficient, all the same. -- Lee On 27/03/14 23:09, Matthew McPherrin wrote: I think your hypothetical situation of saving millions by disabling bounds checks is absurd: To save $10 per machine, assuming $0.20 per kilowatt-hour, and saving 50 nanojoules per bounds check, you'd need to be avoiding about 10^14 check. That's equivalent to avoiding 1 million bounds checks every second. Even if you had hundreds of CPU cores running at full processing power, I would posit that there are bigger problems, and you're probably spending way more power on cache misses or something. On Thu, Mar 27, 2014 at 1:42 PM, Tommi rusty.ga...@icloud.com wrote: On 27 Mar 2014, at 22:17, Steve Klabnik st...@steveklabnik.com wrote: Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks (which people are bound to make with no bounds checking in C++ at least) be more apples-to-apples comparisons. Also, knowing there's a flag in case you need one would put performance-critical people's mind A flag that removes safety is pretty antithical to the goals of the language, IMHO. Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
a) I think Rust is making a mistake by considering boundary checks only on memory accesses b) No, it really wouldn't be ridiculous, if you've checked it properly at a QA stage. By definition, it's ridiculous to KEEP checking it, once it's already been checked thoroughly, as a proper QA process would do. On 27/03/14 23:16, Corey Richardson wrote: It's not about debugging, it's about memory safety. It'd be ridiculous to disable bounds checking just because you've done QA. How many security exploits are over- or under-flows? On Thu, Mar 27, 2014 at 7:16 PM, Lee Braiden leebr...@gmail.com wrote: I think the point is that the compiler should not be forcing people to do things, but enabling people to do things, with sensible defaults. Personally, whilst I would advocate MORE bounds checking in rust for debugging / prototyping purposes, I don't think bounds checking is even ideal. It's a useful tool WHILST prototyping software, but if you really want to ensure quality, you do a full QA process, examining all boundary and corner cases closely. When that's been done, then bounds checks become both unnecessary, and inefficient. No, not massively unnecessary or inefficient, but unnecessary and inefficient, all the same. -- Lee On 27/03/14 23:09, Matthew McPherrin wrote: I think your hypothetical situation of saving millions by disabling bounds checks is absurd: To save $10 per machine, assuming $0.20 per kilowatt-hour, and saving 50 nanojoules per bounds check, you'd need to be avoiding about 10^14 check. That's equivalent to avoiding 1 million bounds checks every second. Even if you had hundreds of CPU cores running at full processing power, I would posit that there are bigger problems, and you're probably spending way more power on cache misses or something. On Thu, Mar 27, 2014 at 1:42 PM, Tommi rusty.ga...@icloud.com wrote: On 27 Mar 2014, at 22:17, Steve Klabnik st...@steveklabnik.com wrote: Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks (which people are bound to make with no bounds checking in C++ at least) be more apples-to-apples comparisons. Also, knowing there's a flag in case you need one would put performance-critical people's mind A flag that removes safety is pretty antithical to the goals of the language, IMHO. Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On Thu, Mar 27, 2014 at 4:51 PM, Lee Braiden leebr...@gmail.com wrote: b) No, it really wouldn't be ridiculous, if you've checked it properly at a QA stage. By definition, it's ridiculous to KEEP checking it, once it's already been checked thoroughly, as a proper QA process would do. I'm not sure what your QA process normally entails, but can it guarantee a build that is free of errors with *zero margin for failure*? Anything less is a step back from what Rust currently provides, IMO. -- Tony Arcieri ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 27/03/14 07:16 PM, Lee Braiden wrote: I think the point is that the compiler should not be forcing people to do things, but enabling people to do things, with sensible defaults. Personally, whilst I would advocate MORE bounds checking in rust for debugging / prototyping purposes, I don't think bounds checking is even ideal. It's a useful tool WHILST prototyping software, but if you really want to ensure quality, you do a full QA process, examining all boundary and corner cases closely. When that's been done, then bounds checks become both unnecessary, and inefficient. No, not massively unnecessary or inefficient, but unnecessary and inefficient, all the same. You're free to opt-in to non-checked indexing on a case-by-case basis where you are reasonably sure it is correct. Rust already has the necessary unsafe indexing support in the standard library. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 27/03/14 04:42 PM, Tommi wrote: A flag that removes safety is pretty antithical to the goals of the language, IMHO. Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. Rust already provides unchecked indexing. You're free to make use of it whenever you want. It makes zero sense to disable the bounds checks for the index operators that are considered safe. What does the unsafe keyword even mean for a project using that flag? Just because something is *possible* does not somehow make it totalitarian to not support it. Rust should not add flags creating incompatible dialects of the language, and that's exactly what this would do. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
Compiling with that flag would figuratively speaking wrap everything inside an unsafe block and then omit vector bounds checking. The flag wouldn't be allowed for library builds. What I find a bit totalitarian about this situation is that the language forces a decision which the programmer should be allowed to make for himself. A bit like someone dictating my hair style. On 28 Mar 2014, at 02:05, Daniel Micay danielmi...@gmail.com wrote: On 27/03/14 04:42 PM, Tommi wrote: A flag that removes safety is pretty antithical to the goals of the language, IMHO. Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. Rust already provides unchecked indexing. You're free to make use of it whenever you want. It makes zero sense to disable the bounds checks for the index operators that are considered safe. What does the unsafe keyword even mean for a project using that flag? Just because something is *possible* does not somehow make it totalitarian to not support it. Rust should not add flags creating incompatible dialects of the language, and that's exactly what this would do. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 27/03/14 09:02 PM, Tommi Tissari wrote: Compiling with that flag would figuratively speaking wrap everything inside an unsafe block and then omit vector bounds checking. The flag wouldn't be allowed for library builds. What I find a bit totalitarian about this situation is that the language forces a decision which the programmer should be allowed to make for himself. A bit like someone dictating my hair style. What would be the meaning in `unsafe` in that new dialect of Rust? We already lint on redundant unsafe blocks, and *all* unsafe blocks would be redundant in that case. It might as well just consider everything to be inside one... signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
Oh, ok, well in that case I suppose the flag should cause all indexing operations to become their unsafe variants instead, all functions that call those to become unsafe, etc. propagating the unsafety where it's needed to make the code compile. On 28 Mar 2014, at 03:15, Daniel Micay danielmi...@gmail.com wrote: On 27/03/14 09:02 PM, Tommi Tissari wrote: Compiling with that flag would figuratively speaking wrap everything inside an unsafe block and then omit vector bounds checking. The flag wouldn't be allowed for library builds. What I find a bit totalitarian about this situation is that the language forces a decision which the programmer should be allowed to make for himself. A bit like someone dictating my hair style. What would be the meaning in `unsafe` in that new dialect of Rust? We already lint on redundant unsafe blocks, and *all* unsafe blocks would be redundant in that case. It might as well just consider everything to be inside one... ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
Opting in case by case is not the same thing as having a compiler flag which you can toggle without modifying the source. Perhaps bounds checking is the only safety measure which has runtime penalty? (Not sure about that) But that would explain why it would be a separate flag. By the way, D is memory safe (although it's opt-in) and it has this noboundscheck flag. So I don't see what the problem is. On 28 Mar 2014, at 03:17, Daniel Micay danielmi...@gmail.com wrote: On 27/03/14 09:02 PM, Tommi Tissari wrote: the language forces a decision which the programmer should be allowed to make for himself. This also isn't true. Rust provides unsafe indexing, and you can opt-in to using it. It also provides a concept of safety as part of the language, and I don't see why it should ignore it for bounds checking while still enforcing a now meaningless separation elsewhere. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 27/03/14 10:04 PM, Tommi Tissari wrote: Opting in case by case is not the same thing as having a compiler flag which you can toggle without modifying the source. A case-by-case basis preserves the safety guarantees of the language and doesn't introduce a new dialect. It also means you can deal with this on a case-by-case basis with careful auditing rather than assuming the entire program is correct. It's not even viewed as *wrong* to do an out-of-bounds index at the moment - it causes failure, not an abort. Perhaps bounds checking is the only safety measure which has runtime penalty? (Not sure about that) But that would explain why it would be a separate flag. There's also dynamic borrow checking on RefCell, and many functions check for integer overflow when it would cause memory unsafety. Lifetimes permit only a subset of the valid uses for references. Do you want a flag to turn off lifetime checking too? That would mean 4 language dialects (no_bounds_check, no_bounds_check+no_lifetime_check, no_lifetime_check, rust). Should the entire test suite (excluding intentionally changed ones) be run for each supported language subset? I'm sure we have at least one test checking for bounds-checking failure. By the way, D is memory safe (although it's opt-in) and it has this noboundscheck flag. So I don't see what the problem is. D is *not* memory-safe, with or without the noboundscheck flag... the flag makes it less memory safe than it already is, of course. If you're counting the crippled subset of the language available in functions marked safe, then sure - but that's not anything like Rust. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 03/27/2014 10:04 PM, Tommi Tissari wrote: By the way, D is memory safe (although it's opt-in) and it has this noboundscheck flag. So I don't see what the problem is. Rust takes a very different stance to safety than to D (e.g. making it safe by default). In the D community my perception was that for any benchmark written in D it has been the suggestion to turn on that noboundscheck flag in order to get extra speed, forming a perception that D is only fast if you turn off this safety feature completely. Not only is Rust's approach more fine grained (although it is possible to do unsafe array access in specific locations in D as well), but it also encourages Rust to be fast /despite/ the safety features. A big reason for Rusts existence is that it wants to provides C++-level performance while /at the same time/ providing safety. If the only way a Rust user can match C++ speed is by using 'unsafe' everywhere, then Rust will have failed, in my opinion. I didn't look at how the shootout benchmarks are implemented, but if I had any say, I'd forbid them to use any unsafe code (except for FFI where absolutely necessary) to prove the above point. There are many ways you can avoid bounds checks in safe Rust code. For example, if you restrict yourself to using iterators instead of indexing operators, there will be no bounds checks. You can also code up abstractions (like I did in my matrix library) so that you don't need to pay the bounds check cost as much as well. I really don't think this is a real concern. -SL ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 28 Mar 2014, at 03:41, Jeffery Olson olson.jeff...@gmail.com wrote: forces a decision which the programmer should be allowed to make for himself. A bit like someone dictating my hair style. Yes. Rust is just like hair salon that forbids you from setting your own hair on fire. Yes. Rust is just like hair salon that forbids you from setting your own hair on fire. I rather feel like Rust lets me use only dull scissors so that I don't accidentally cut myself. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
If you want sharp scissors, use unsafe indexing. You generally don't need it everywhere, just in your inner loop. Profile, then optimize. Rust gives you the tools needed to optimize where things get hot, but we also like safety by default. - Clark On Thu, Mar 27, 2014 at 10:31 PM, Tommi Tissari rusty.ga...@icloud.comwrote: On 28 Mar 2014, at 03:41, Jeffery Olson olson.jeff...@gmail.com wrote: forces a decision which the programmer should be allowed to make for himself. A bit like someone dictating my hair style. Yes. Rust is just like hair salon that forbids you from setting your own hair on fire. I rather feel like Rust lets me use only dull scissors so that I don't accidentally cut myself. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
Case by case is all fine and good. But you're trying argue what a programmer *should* do if he knew what was good for him. While I'm trying to argue that the programmer should be *free* to test how fast his code would run without bounds checking, just for the hell of it. You want to enforce best practices while I want to allow freedom to choose. I don't know about those other dialects. In D, if you put the label safe in the beginning of each module and compile it with safe flag (and not with noboundscheck flag), then it is memory safe barring compiler bugs. It doesn't allow you to use pointer arithmetic or unsafe casts or call unsafe functions, but that's hardly what I'd call a *crippled* subset of the language. But the point was that D has a memory safe subset and a noboundscheck flag which obviously makes the compilation *not* memory safe. And I was wondering why can't rust have this flag too. On 28 Mar 2014, at 04:26, Daniel Micay danielmi...@gmail.com wrote: On 27/03/14 10:04 PM, Tommi Tissari wrote: Opting in case by case is not the same thing as having a compiler flag which you can toggle without modifying the source. A case-by-case basis preserves the safety guarantees of the language and doesn't introduce a new dialect. It also means you can deal with this on a case-by-case basis with careful auditing rather than assuming the entire program is correct. It's not even viewed as *wrong* to do an out-of-bounds index at the moment - it causes failure, not an abort. Perhaps bounds checking is the only safety measure which has runtime penalty? (Not sure about that) But that would explain why it would be a separate flag. There's also dynamic borrow checking on RefCell, and many functions check for integer overflow when it would cause memory unsafety. Lifetimes permit only a subset of the valid uses for references. Do you want a flag to turn off lifetime checking too? That would mean 4 language dialects (no_bounds_check, no_bounds_check+no_lifetime_check, no_lifetime_check, rust). Should the entire test suite (excluding intentionally changed ones) be run for each supported language subset? I'm sure we have at least one test checking for bounds-checking failure. By the way, D is memory safe (although it's opt-in) and it has this noboundscheck flag. So I don't see what the problem is. D is *not* memory-safe, with or without the noboundscheck flag... the flag makes it less memory safe than it already is, of course. If you're counting the crippled subset of the language available in functions marked safe, then sure - but that's not anything like Rust. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 27/03/14 11:04 PM, Tommi Tissari wrote:
Case by case is all fine and good. But you're trying argue what a programmer
*should* do if he knew what was good for him.
Rust doesn't view the programmer as an infallible, trusted entity. This
is clear in the design of lifetimes. For example, consider this generic
function:
fn foo'a, T(x: 'a [T]) - 'a T { ... }
The compiler substitutes in the type parameter `T` and generates a
specialized function. However, lifetimes are simply erased after
type-checking - they can simply become 'static without any changes to
the compiled code.
While I'm trying to argue that the programmer should be *free* to test how
fast his code would run without bounds checking, just for the hell of it. You
want to enforce best practices while I want to allow freedom to choose.
It's not simply a best practice. It's part of Rust's safety contract,
which is a fundamental part of the language. It influences most aspects
of the language's design.
I don't know about those other dialects.
You're proposing introducing new dialect of Rust.
In Crust, code generating a failure on out-of-bounds will now cause
silent memory corruption. Crust will do away with safety boundaries
completely by making `unsafe` and lifetimes a no-op in order to be a
true superset of Rust.
In Frust, indexing slices is considered an unsafe operation. Very little
existing Rust code will compile under Frust, and some previously safe
checked indexing inside existing `unsafe` blocks will cause silent
memory corruption.
I'm not sure which of these dialects you're proposing, but either one
would require a new set of buildbots to run the tests again. Both the
Crust and Frust languages would require many changes to the
documentation and code of the Rust libraries too.
You're free to fork the language if you want to fundamentally change the
basic semantics of the language. I hope it's clear why this isn't going
to be acceptable upstream.
In D, if you put the label safe in the beginning of each module and compile
it with safe flag (and not with noboundscheck flag), then it is memory safe
barring compiler bugs. It doesn't allow you to use pointer arithmetic or
unsafe casts or call unsafe functions, but that's hardly what I'd call a
*crippled* subset of the language.
D doesn't even let you use ranges (iterators) in safe code. There are
barely any safe functions here, and that's true of most of the standard
library:
http://dlang.org/phobos/std_range.html
But the point was that D has a memory safe subset and a noboundscheck flag
which obviously makes the compilation *not* memory safe. And I was wondering
why can't rust have this flag too.
Rust is a memory safe language with a crippled unsafe subset. D is an
unsafe language with a crippled safe subset. Something that may make
sense in the language design for D does not necessarily make sense in
Rust. If you want D, then please go ahead and use D.
In Rust, bounds check failures are not currently viewed as a logic
error. They are a normal runtime failure that can be handled at a task
boundary. You're going to need to convince us to consider them a logic
error *before* you bring the option of a subset of Rust without logic
error checks to the table. The standard library (and others) currently
rely on this being a failure to guarantee safety elsewhere. Take away
this check and there is no safety even in code without array indexing.
signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 3/27/14 1:42 PM, Tommi wrote: On 27 Mar 2014, at 22:17, Steve Klabnik st...@steveklabnik.com wrote: Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks (which people are bound to make with no bounds checking in C++ at least) be more apples-to-apples comparisons. Also, knowing there's a flag in case you need one would put performance-critical people's mind A flag that removes safety is pretty antithical to the goals of the language, IMHO. Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. I think that Rust should give you the ability to opt out of safety, but on a per-operation basis. Having it as a compiler option is too much of a sledgehammer: often you want some non-performance-critical bounds to be checked in the name of safety, while you want some bounds checks to be turned off. In fact, this is precisely what Rust allows today, via the `.unsafe_get()` and `.unsafe_set()` methods. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
I'd like to point out that I agree with your central premise that most
bounds checks are useless. Some huge percentage of them, in fact.
But I still enjoy the peace of mind that they bring. If I actually need a
piece of code to be manually checked, covered in tests, and benchmarked to
be fast, I'll do that. Then I'll switch to unsafe accesses in my hot paths.
I'm not sure I'm comfortable with people just arbitrarily switching off
bounds checking to exchange an unnoticeable 3% (ballpark) performance
increase for unknown security attack vectors.
For example, do you really want your entire application to be at risk just
because you didn't want bounds checking in some logging code that's never
touch in your fast-paths? That just seems silly to me.
- Clark
On Thu, Mar 27, 2014 at 11:48 PM, Daniel Micay danielmi...@gmail.comwrote:
On 27/03/14 11:04 PM, Tommi Tissari wrote:
Case by case is all fine and good. But you're trying argue what a
programmer *should* do if he knew what was good for him.
Rust doesn't view the programmer as an infallible, trusted entity. This
is clear in the design of lifetimes. For example, consider this generic
function:
fn foo'a, T(x: 'a [T]) - 'a T { ... }
The compiler substitutes in the type parameter `T` and generates a
specialized function. However, lifetimes are simply erased after
type-checking - they can simply become 'static without any changes to
the compiled code.
While I'm trying to argue that the programmer should be *free* to test
how fast his code would run without bounds checking, just for the hell of
it. You want to enforce best practices while I want to allow freedom to
choose.
It's not simply a best practice. It's part of Rust's safety contract,
which is a fundamental part of the language. It influences most aspects
of the language's design.
I don't know about those other dialects.
You're proposing introducing new dialect of Rust.
In Crust, code generating a failure on out-of-bounds will now cause
silent memory corruption. Crust will do away with safety boundaries
completely by making `unsafe` and lifetimes a no-op in order to be a
true superset of Rust.
In Frust, indexing slices is considered an unsafe operation. Very little
existing Rust code will compile under Frust, and some previously safe
checked indexing inside existing `unsafe` blocks will cause silent
memory corruption.
I'm not sure which of these dialects you're proposing, but either one
would require a new set of buildbots to run the tests again. Both the
Crust and Frust languages would require many changes to the
documentation and code of the Rust libraries too.
You're free to fork the language if you want to fundamentally change the
basic semantics of the language. I hope it's clear why this isn't going
to be acceptable upstream.
In D, if you put the label safe in the beginning of each module and
compile it with safe flag (and not with noboundscheck flag), then it is
memory safe barring compiler bugs. It doesn't allow you to use pointer
arithmetic or unsafe casts or call unsafe functions, but that's hardly what
I'd call a *crippled* subset of the language.
D doesn't even let you use ranges (iterators) in safe code. There are
barely any safe functions here, and that's true of most of the standard
library:
http://dlang.org/phobos/std_range.html
But the point was that D has a memory safe subset and a noboundscheck
flag which obviously makes the compilation *not* memory safe. And I was
wondering why can't rust have this flag too.
Rust is a memory safe language with a crippled unsafe subset. D is an
unsafe language with a crippled safe subset. Something that may make
sense in the language design for D does not necessarily make sense in
Rust. If you want D, then please go ahead and use D.
In Rust, bounds check failures are not currently viewed as a logic
error. They are a normal runtime failure that can be handled at a task
boundary. You're going to need to convince us to consider them a logic
error *before* you bring the option of a subset of Rust without logic
error checks to the table. The standard library (and others) currently
rely on this being a failure to guarantee safety elsewhere. Take away
this check and there is no safety even in code without array indexing.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Clark.
Key ID : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compiling with no bounds checking for vectors?
On 27/03/14 11:56 PM, Clark Gaebel wrote: I'd like to point out that I agree with your central premise that most bounds checks are useless. Some huge percentage of them, in fact. In my opinion, this isn't necessarily true for Rust. Iterators provide a lot of functionality without the overhead of bounds checks, such as the ability to reverse the elements of any container without overhead by leveraging double-ended iterators. Many common uses of slices can be encoded as iterators (like chunks and windows) too. I'm not sure I'm comfortable with people just arbitrarily switching off bounds checking to exchange an unnoticeable 3% (ballpark) performance increase for unknown security attack vectors. I think the performance increase will often be far larger in cases where bounds checks are in the hot path. The branch itself might not be a big deal, but it will often prevent further optimization. For example, do you really want your entire application to be at risk just because you didn't want bounds checking in some logging code that's never touch in your fast-paths? That just seems silly to me. Exactly. Only a subset of the bounds checks are going to be a performance issue, and only a further subset of those are going to be possible to remove. Many are going to need to stay, whether or not they are coming from the [] syntax or an explicit check. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
