Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How much does Rust's bounds checking cost?

blog.readyset.io

Post reply on HN
Print view View original

141–150 of 195 posts

Re: How much does Rust's bounds checking cost?

#141

Post by brundolf »

nindalf wrote: post #128
est31 wrote: post #95

Earlier quoted context omitted.

It will still implement that with a loop over the array where there is a (bounds) check for the integer when it's being incremented (the i do have an advantage however, compilers can see their size so if you have an array (or array reference) and index it with a constant, then that bounds check will be eliminated. Also, array references are cheaper than slices because slices always contain the length.

> Arrays do have an advantage however, compilers can see their size Wouldn’t vectors have the same advantage in Rust? If we’re iterating over a vector, it’s proveable at compile time that the length is not being modified during the iteration.

Length not being modified during iteration sure, but not the exact length. It's not possible in the general case to determine the exact length of a Vec at compile time, whereas Rust arrays can never change length so their exact length is know statically (unless you've got a slice, which is different)

Re: How much does Rust's bounds checking cost?

#142

Post by varajelle »

moloch-hai wrote: post #119
dataangel wrote: post #78

Earlier quoted context omitted.

They’re nowhere near free. Branch prediction table has finite entries, instruction cache has finite size, autovectorizing is broken by bounds checks, inlining (the most important optimization) doesn’t trigger if functions are too big because of the added bounds checking code, etc. This is just not great benchmarking — no effort to control for noise.

For real programs, you should demand that the compiler hoist such checks out of the loop, which may then be vectorized the usual way. If the compiler can't do that by itself, a library should do it. The real issue is whether the information about the true size of the memory region involved is available at the point where it is needed. This may come down to how good the language is at capturing desired semantics in a…

> This may come down to how good the language is at capturing desired semantics in a library. Rust still has a long way to go to catch up with C++ on this axis, and C++ is not waiting around.

What catch up does Rust need to do?

Rust has slice that know the size of its data built in the language, while C++ doesn't. And Rust has stricter const and mutability rules that facilitates optimizations.

As for the implementation, Rust use LLVM which is also the backend used by one of the popular C++ compiler.

Re: How much does Rust's bounds checking cost?

#143

Post by skyde »

netr0ute wrote: post #137
kelnos wrote: post #133

Earlier quoted context omitted.

And that's the thing, really. Sure, they're not free, but they're pretty cheap. In a project like OpenSSL, if C had bounds checking, it should be enabled, all the time. Sure, disable it for some random bit of custom high-perf software where you really need to eke out the last few percent of performance. But for 99% of everything else, leave the bounds checking turned on.

I don't know, because if you're writing programs for things like IoT or embedded, then you're dealing with nothing but wimpy little low power processors where removing a bounds check gives you huge increases. Then, it makes no sense to have checks by default if you're going to get rid of them anyway.

if it’s a 4% gain. then it’s the same 4% game no matter if running on a big fast cpu or a 8bit micro controller. right?

Re: How much does Rust's bounds checking cost?

#144

Post by Kamq »

kelnos wrote: post #133
fear91 wrote: post #96

Earlier quoted context omitted.

I have removed signed-integer based values bounds checking in a compiler once and before I noticed, I got a nice 3.8% performance gain in a large diverse benchmarking suite. While not expensive, bounds checks are certainly not free.

And that's the thing, really. Sure, they're not free, but they're pretty cheap. In a project like OpenSSL, if C had bounds checking, it should be enabled, all the time. Sure, disable it for some random bit of custom high-perf software where you really need to eke out the last few percent of performance. But for 99% of everything else, leave the bounds checking turned on.

> Sure, disable it for some random bit of custom high-perf software where you really need to eke out the last few percent of performance.

And that's the rub, isn't it? Getting that last bit of perf in the inner hot loop has traditionally often required people to write the entire thing in languages that are unsafe (ffi overhead often being enough that you can't just wrap up the hot loop and call the bit that needs to be performant from elsewhere).

I wonder how much good interop could get us.

Re: How much does Rust's bounds checking cost?

#145

Post by moloch-hai »

varajelle wrote: post #142
moloch-hai wrote: post #119

Earlier quoted context omitted.

For real programs, you should demand that the compiler hoist such checks out of the loop, which may then be vectorized the usual way. If the compiler can't do that by itself, a library should do it. The real issue is whether the information about the true size of the memory region involved is available at the point where it is needed. This may come down to how good the language is at capturing desired semantics in a…

> This may come down to how good the language is at capturing desired semantics in a library. Rust still has a long way to go to catch up with C++ on this axis, and C++ is not waiting around. What catch up does Rust need to do? Rust has slice that know the size of its data built in the language, while C++ doesn't. And Rust has stricter const and mutability rules that facilitates optimizations. As for the implementati…

I am talking about language features that library authors can use to capture and express semantics in their libraries... but only if the language implements those features. C++ just has a lot more of them.

Re: How much does Rust's bounds checking cost?

#146

Post by xyzzyz »

moloch-hai wrote: post #145
varajelle wrote: post #142

Earlier quoted context omitted.

> This may come down to how good the language is at capturing desired semantics in a library. Rust still has a long way to go to catch up with C++ on this axis, and C++ is not waiting around. What catch up does Rust need to do? Rust has slice that know the size of its data built in the language, while C++ doesn't. And Rust has stricter const and mutability rules that facilitates optimizations. As for the implementati…

I am talking about language features that library authors can use to capture and express semantics in their libraries... but only if the language implements those features. C++ just has a lot more of them.

Like what, for example? To the contrary, I think that, other than constness, C++ has rather few facilities to communicate semantic invariants to the compiler.

Re: How much does Rust's bounds checking cost?

#147

Post by masklinn »

akshaykarthik wrote: post #131
ridiculous_fish wrote: post #112

Earlier quoted context omitted.

IME loops with induction variables (integer indexes) often produces better codegen than with iterators. Compare the these two Rust functions for inverting bits: https://rust.godbolt.org/z/cE4vPdbdY This got improved in Rust 1.65 just this month, but the point stands. edit : ARM64 compilation is even sillier. https://rust.godbolt.org/z/PEsbeGxWP

Interestingly enough, with `-C opt-level=3` both functions yield the same assembly. I wonder if there's some pass that's missing or not done at the lower opt level.

Might be a problem of the number of pass repetitions, where O2 does not rerun the vectorisation after whatever manages to unroll everything but O3 does.

Re: How much does Rust's bounds checking cost?

#148

Post by nextaccountic »

moloch-hai wrote: post #119
dataangel wrote: post #78

Earlier quoted context omitted.

They’re nowhere near free. Branch prediction table has finite entries, instruction cache has finite size, autovectorizing is broken by bounds checks, inlining (the most important optimization) doesn’t trigger if functions are too big because of the added bounds checking code, etc. This is just not great benchmarking — no effort to control for noise.

For real programs, you should demand that the compiler hoist such checks out of the loop, which may then be vectorized the usual way. If the compiler can't do that by itself, a library should do it. The real issue is whether the information about the true size of the memory region involved is available at the point where it is needed. This may come down to how good the language is at capturing desired semantics in a…

> For real programs, you should demand that the compiler hoist such checks out of the loop, which may then be vectorized the usual way.

LLVM sometimes does this, but when it doesn't, you may insert asserts to guide the optimizer, as explained here https://news.ycombinator.com/item?id=33808853

I think this technique works in C and C++ too (if you use clang or gcc)

Re: How much does Rust's bounds checking cost?

#149

Post by winrid »

brundolf wrote: post #84

One thing that I assume reduces this problem even further is the prevalent use of iterators in Rust. I almost never index an array or vector directly, which means it's impossible for me to use an out of bounds index, and I'd be really surprised if rustc and/or LLVM don't somehow take advantage of that fact (maybe just through unchecked indexing in the standard library's iterator functions)

IIRC the Rust in Action book claimed iterators usually omit bounds checks, but if you manually index into the array then it's more likely the bounds check won't be optimized out.

Re: How much does Rust's bounds checking cost?

#150

Post by varajelle »

xyzzyz wrote: post #146
moloch-hai wrote: post #145

Earlier quoted context omitted.

I am talking about language features that library authors can use to capture and express semantics in their libraries... but only if the language implements those features. C++ just has a lot more of them.

Like what, for example? To the contrary, I think that, other than constness, C++ has rather few facilities to communicate semantic invariants to the compiler.

And event const can't in general be used for optimizations (because there can be another reference to the same location, or one can just const_cast)
Post reply on HN