How much does Rust's bounds checking cost? • Hacker News Board

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

#101

Post by [deleted] » Thu, Dec 01, 2022, 12:08 AM UTC

dataangel wrote: post #78

Jach wrote: post #45

Always amuses me that it's current year and people think about turning off checks, even when they're pretty much free in modern* (since 1993 Pentium, which got like 80% accuracy with its primitive branch prediction?) CPUs... "Around Easter 1961, a course on ALGOL 60 was offered … After the ALGOL course in Brighton, Roger Cook was driving me and my colleagues back to London when he suddenly asked, "Instead of designin…

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.

[deleted]

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

#102

Post by worewood » Thu, Dec 01, 2022, 12:20 AM UTC

99. ..% of "real" applications are bottlenecked by I/O, be it disk or network or synchronization (as in, waiting for something else to happen)

If you're not in a HPC or heavily resource constrained context you can safely ignore the performance implications of choosing whatever programming language you like.

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

#103

Post by dahfizz » Thu, Dec 01, 2022, 12:36 AM UTC

dataangel wrote: post #78

Jach wrote: post #45

Always amuses me that it's current year and people think about turning off checks, even when they're pretty much free in modern* (since 1993 Pentium, which got like 80% accuracy with its primitive branch prediction?) CPUs... "Around Easter 1961, a course on ALGOL 60 was offered … After the ALGOL course in Brighton, Roger Cook was driving me and my colleagues back to London when he suddenly asked, "Instead of designin…

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.

> autovectorizing is broken by bounds checks

This is the big one. You pay a 50% penalty for actual CPU bound, iteration heavy code with bounds checking enabled.

https://github.com/matklad/bounds-check-cost

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

#104

Post by [deleted] » Thu, Dec 01, 2022, 12:37 AM UTC

tester756 wrote: post #58

humanrebar wrote: post #53

Earlier quoted context omitted.

All of the CPUs? C runs a lot of places.

If you need perf, then consider better algorithms, better data structures, multi-threading, branchless programming (except safety), data-oriented design and then elimination of checks, not first.

[deleted]

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

#105

Post by int_19h » Thu, Dec 01, 2022, 12:37 AM UTC

constantcrying wrote: post #32

I imagine the reason bounds check are cheap is because of the branch predictor. If you always predict the in bounds path, the check is almost free. You also do not really care about flushing the pipe on an out of bounds index, since very likely normal operations can not go on and you move over to handling/reporting the error, which likely has no need for significant throughput. Also I would just like to note that saf…

It's not hard, but when the idiomatically used containers aren't bounds-checked, most code out in the wild won't be, either. Worse yet if you are writing a library and have to interop with other code which will also use those idiomatic types.

These days, C++ really should be compiled with bounds-checked indexing and iterators by default. Unfortunately, this is still not a scenario that is well-supported by tooling.

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

#106

Post by dahfizz » Thu, Dec 01, 2022, 12:40 AM UTC

This is a pretty unsatisfying benchmark. Can we pin the thread to a core and re-run a few times to de-noise? And how about using an actual CPU bound program? Even a significant speedup in the code will be lost in an application like this where you spend so much time in I/O.

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

#107

Post by int_19h » Thu, Dec 01, 2022, 12:43 AM UTC

tylerhou wrote: post #71

apendleton wrote: post #68

Earlier quoted context omitted.

I think we're suffering from some fuzziness about what bounds checks we're referring to. Even in your example, you only need to check the size of the Vec when you instantiate the iterator, not each time the iterator accesses an element, because at the time the iterator over the Vec 's contents is instantiated, the Vec 's size is known, and it can't change over the life of the iterator (because mutation is disallowed…

When I read "iterator" I think of an object that points into the vector and can be advanced. For Rust's vector, that is std::slice::Iter ( https://doc.rust-lang.org/std/slice/struct.Iter.html ). When you advance an iterator, you must do a bounds check if the vector is dynamically sized; otherwise, you don't know when to stop. I.e., if I have let mut it = vec.iter(); println!(it.next()); println!(it.next()); println!(…

That's not an index-out-of-bounds check tho, that's just the regular loop exit condition. In a C-style for(i=0; iThe check that can (and is) elided by the iterator here is the one that would be in the body of the loop, when you try to use i to index into the array. The nice thing about it is that it doesn't require the compiler to be smart at all.

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

#108

Post by cyber_kinetist » Thu, Dec 01, 2022, 12:46 AM UTC

This is one of the main reason you should use indices instead of pointers to store references to other objects (regardless of if you’re using Rust or C++): memory safety. Indices can be bound-checked, pointers can’t.

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

#109

Post by dahfizz » Thu, Dec 01, 2022, 1:01 AM UTC

tester756 wrote: post #52

I've been shocked when I've heard C programmers being actually concerned about performance penalty of checks like, why bother? CPUs in next 2 years will win that performance anyway and your software will be safer

This is mostly true. The one exception is when bounds checking prevents the compiler from vectorizing your code. Then you may pay up to a 50% penalty for the innocent looking `if`.

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

#110

Post by azylman » Thu, Dec 01, 2022, 1:04 AM UTC

worewood wrote: post #102

99. ..% of "real" applications are bottlenecked by I/O, be it disk or network or synchronization (as in, waiting for something else to happen) If you're not in a HPC or heavily resource constrained context you can safely ignore the performance implications of choosing whatever programming language you like.

This isn't really true, some languages handle I/O much better than other languages. We migrated a Python application to Go that was about as simple as you can get and mostly blocked by I/O (call DB, transform storage format to Thrift, respond to caller with Thrift) and saw SUBSTANTIAL improvements in performance. Approximately 40% improvement in p99 latency and, more notably, 15x improvement in throughput.