4 ms·
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 i
by 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 agoYou just linked to the same line four times. :P
- acconsta 11y agoOh, oops. 471, 508 679, 766.
- kibwen 11y agoGiven 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 agoMe too. I've been thinking about doing an analogous benchmark in C++ for a while.