Hacker News Reader

Comment by acconsta | Hacker News Reader

>We need to move forward to Rust

In fairness, C++ containers know their size. And Rust's solution to buffer overflows is the same as every other language — run time bounds checking.

View on HN

Most of the time, you'll be accessing Rust collections through iterators, and iterators fold the bounds-check into the termination condition. There's no additional overhead here; it compiles into the exact same code that the C would.

If you're using iterators, you don't have to worry about buffer overflow. But every A[i] random access needs to be bound checked.

Although the bounds check can also be elided if the compiler knows i < len

Right. I think that's mostly immutable containers though, right? Or is the compiler smarter than that?

> And Rust's solution to buffer overflows is the same as every other language — run time bounds checking.

Right, because that's the only way to do it? What's wrong with that?

The point is a language like Rust has built-in bounds checking...

So does C++: http://www.cplusplus.com/reference/stdexcept/out_of_range/

>The point is a language like Rust has built-in bounds checking...

As does C++. See e.g. vector.at and libstdc++ debug mode:

https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.h...

The difference is only opt-in vs. opt-out. To its credit, Rust provides additional protections against iterator invalidation and dangling pointers, but its approach to buffer overflows is the same.

The trend is towards optimizing out bounds checks for at least the easy cases, such as FOR loops. Go does this. Rust should, and probably will soon. That tends to get most of the inner loops where it really matters, like a matrix multiply. C++ can't do that because the compiler doesn't know that a template-implemented bounds check is a bounds check.

Also, in C++ containers, ".at()" is usually checked, but "[]" is not. So C++ code still regularly has buffer overflow problems.

Rust does optimize iterators, just not random access. You can even turn off the bound checks with get_unchecked, if you really really need unchecked random access.

(and for loops use iterators under the hood)

> Go does this. Rust should, and probably will soon.

LLVM does optimize these out, and in more cases than Go does.

> C++ can't do that because the compiler doesn't know that a template-implemented bounds check is a bounds check.

It doesn't need to. SCCP is a very general optimization. GCC and LLVM optimize out bounds checks in more cases than Go can do.

> Right, because that's the only way to do it? What's wrong with that?

Maybe the fact that it's wrong? Compile-time bounds checking is such a classic "hello world" example for type checkers that it's become a cliche (eg. https://www.quora.com/What-are-some-good-examples-of-practic... )

Dependent types make zero-overhead bound checking trivial. More recently, less powerful type systems like liquid types have been proposed (because reasons). Zero-overhead bound checking is usually on their feature list, since a) it's ubiquitous b) it's easy.

Great! Please implement them in Rust as soon as possible.

But until then, Rust's approach is runtime bounds checking.

I don't know about Rust, I've never used it (and I rarely use C). However, I do use dependently typed languages every day, so I was replying to refute the "that's the only way to do it" argument.

For... building software? I thought dependent types haven't escaped research languages.

Can't you turn them off though?

Not with a flag or anything. As said above, if you use iterators, it's not generally an issue, or you can call an unsafe function that doesn't do the check.

You can opt out of bounds checking by using the unsafe `get_unchecked` method instead of the array indexing syntax. There's no compiler flag to turn off bounds checking, because the language doesn't want to encourage memory safety that's dependent only on compiler flags (and also because the cost of runtime bounds checking in real programs is indistinguishable from noise).

>the cost of runtime bounds checking in real programs is indistinguishable from noise

Can you show us the benchmarks for that?

The source of my assertion comes from repeated conversations with the Servo developers, who have written many hundreds of thousands of lines of Rust in a project whose goal is to be twice as fast as modern web browsers (in other words, they are comparing themselves to programs written in C++, and speed matters). They regularly profile in pursuit of tracking down inefficiencies, and bounds checking has never been even a blip on their radar. Quotes from the exchange I've had just now with pcwalton: "I haven't done rigorous benchmarking but I have never seen it in instruction level profiles [...] I'd rather just spend my time shipping software that uses fast bounds checks and prove it that way :) [...] my point is simply that the delta between idiomatic Rust code that uses iterators and no bounds checks and the idiomatic Rust code that uses iterators and bounds checks is incredibly small since bounds checks are so rare to begin with" (http://logs.glob.uno/?c=mozilla%23servo#c271807)

As for actual benchmarks, I think they would actually be quite easy to produce. There's exactly one line in the Rust stdlib that provides bounds checking for indexing, right here: https://github.com/rust-lang/rust/blob/master/src/libcore/sl... . All you would need to do is take out that line and compile Servo with your modified stdlib and compare the results of running the built-in benchmarks. I may just do this myself as a blog post. :)

OK, data definitely helps. It's not always easy to predict what modern CPUs will do!

For the record, there seem to be a lot of bounds checking independent of indexing:

https://github.com/rust-lang/rust/blob/master/src/libcollect...

You just linked to the same line four times. :P

Oh, oops. 471, 508 679, 766.

Given that these are all achieved with the `assert!` macro, we can fortunately just redefine the macro to be a no-op in order to determine the runtime cost of all assertions in the standard library (note that assertions that aren't required for memory safety should already be using the `debug_assert!` macro, which is in fact compiled to a no-op in non-debug builds). This will overestimate the impact of removing bounds checks (since we'll potentially be removing lots else as well), but I'm curious to see if the performance impact will still be negligible regardless.

Me too. I've been thinking about doing an analogous benchmark in C++ for a while.

Reply on news.ycombinator.com