7 ms·

>the cost of runtime bounds checking in real programs is indistinguishable from noise Can you show us the benchmarks for that?

kibwen 11y ago
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 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/slice.rs#L552 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. :)
- deleted 11y ago
  [deleted]
- acconsta 11y ago
  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/libcollections/vec.rs#L471 https://github.com/rust-lang/rust/blob/master/src/libcollect... https://github.com/rust-lang/rust/blob/master/src/libcollections/vec.rs#L471 https://github.com/rust-lang/rust/blob/master/src/libcollect... https://github.com/rust-lang/rust/blob/master/src/libcollections/vec.rs#L471 https://github.com/rust-lang/rust/blob/master/src/libcollect... https://github.com/rust-lang/rust/blob/master/src/libcollections/vec.rs#L471 https://github.com/rust-lang/rust/blob/master/src/libcollect...
  - kibwen 11y ago
    You just linked to the same line four times. :P
    - acconsta 11y ago
      Oh, oops. 471, 508 679, 766.
      - kibwen 11y ago
        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.
        acconsta 11y ago
        Me too. I've been thinking about doing an analogous benchmark in C++ for a while.

kibwen 11y ago

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 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/slice.rs#L552 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. :)

deleted 11y ago
[deleted]
acconsta 11y ago
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/libcollections/vec.rs#L471 https://github.com/rust-lang/rust/blob/master/src/libcollect... https://github.com/rust-lang/rust/blob/master/src/libcollections/vec.rs#L471 https://github.com/rust-lang/rust/blob/master/src/libcollect... https://github.com/rust-lang/rust/blob/master/src/libcollections/vec.rs#L471 https://github.com/rust-lang/rust/blob/master/src/libcollect... https://github.com/rust-lang/rust/blob/master/src/libcollections/vec.rs#L471 https://github.com/rust-lang/rust/blob/master/src/libcollect...
- kibwen 11y ago
  You just linked to the same line four times. :P
  - acconsta 11y ago
    Oh, oops. 471, 508 679, 766.
    - kibwen 11y ago
      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.
      - acconsta 11y ago
        Me too. I've been thinking about doing an analogous benchmark in C++ for a while.