Hacker News Reader

Comment by CJefferson | Hacker News Reader

I just want to pick out one thing:

It would (or should) crash your program in any other language anyway.

To me there is a massive difference between "there is a way a malicious user can trigger an assert, which will crash your server / webbrowser", and "there is a way a malicious user can use memory corruption to take over your server / webbrowser".

And bounds-checking penalties are small. I can tell they are small, because Rust doesn't have any kind of clever 'global way' of getting rid of them, and I've only noticed the cost showing up in profiles twice. In those cases I did very carefully verify my code, then turn off the bounds checking -- but that's fine, I'm not saying we should never bounds check, just we should do it by default. Do you have any evidence the costs are expensive?

View on HN

If you profile looping through an array of pixels in linear memory order vs bounds checking every access it should be more expensive due to the branching.

As someone else mentioned you can boundary check access if you want to in C++ anyway and it's built in to a vector.

My point here is that it isn't really a big problem with C++, you can get what you want.

Iterating over an array in Rust does not involve bounds checking every access since Rust guarantees immutability to the container over the course of the iteration. Hence all that's needed is to access the size of the array at the start of the iteration and then it is safe to iterate over the entire array.

Note that this is not something C++ is able to do, and C++ has notoriously subtle iterator invalidation rules as a consequence.

They asked for evidence of bounds checks being expensive, please try to keep the context in mind.

Note that this is not something C++ is able to do

Or you could just not mutate the container.

It's the optimization that C++ is unable to perform, not the immutability.

If you declare using an invalidated iterator as UB, the compiler can optimize as if the container was effectively immutable during the loop.

Are you talking about optimizing out bounds checking that isn't happening in the first place?

> "They asked for evidence of bounds checks being expensive"

They said "bounds-checking penalties are small" not that it was free. You've described a situation where bounds checking happens and declared that it "should be" expensive because it happens. You haven't given evidence that it's expensive.

I didn't give direct evidence, that's true.

You can profile it yourself, but it is the difference between direct access to cached memory (from prefetching) and two comparisons plus two branches then the memory access.

To someone who doesn't care about performance having something trivial become multiple times the cost might be acceptable (people use scripting languages for a reason), but if your time is spent looping through large amounts of data, that extra cost is a problem.

Reply on news.ycombinator.com