3 ms·

Modern CPU design adds an interesting twist to the bounds checking question that (imo) renders it moot. At least on Intel CPUs, the array bounds check gets com

Modern CPU design adds an interesting twist to the bounds checking question that (imo) renders it moot. At least on Intel CPUs, the array bounds check gets compiled down to a compare-and-jump instruction pair, which then ends up getting run as a single microinstruction on the CPU. Unless you're in an extremely tight loop, the cost of that instruction just isn't significant. The only time it costs much at all is in the event of a branch misprediction, in which case the very next thing that's going to happen is an exception so it's still insignificant given the context. And if you are in an extremely tight loop, it's probably structured in a way that makes it easy for compiler optimize away the bounds check.

srean 13y ago
I am willing to be convinced, but it will take a well executed BLAS (, in particular a sparse BLAS) benchmark with and without range checks. If the range check enabled version is within 5~8% of the current standard of say a ATLAS/MKL/Eigen (note these aren't quite the fastest) consider me sold. In my experience range checks did affect the speed, but range check alone may not be to blame. It might well be that code pieces became a tad bit larger than what a compiler would automatically inline, and those snow-balled. In case you have such a benchmark handy would appreciate a link 'cause fast is good, but fast and correct is way better.
- bunderbunder 13y ago
  If you're really in a position where you need to worry about performance down to the level of counting individual instructions then you probably shouldn't be relying on someone else to do your benchmarks for you, anyway.
  - srean 13y ago
    Where did you get the "counting individual instructions" from ? I continue to remain willing to be convinced if someone provides the benchmarks, mine own turned out to be disappointing.

srean 13y ago

I am willing to be convinced, but it will take a well executed BLAS (, in particular a sparse BLAS) benchmark with and without range checks. If the range check enabled version is within 5~8% of the current standard of say a ATLAS/MKL/Eigen (note these aren't quite the fastest) consider me sold. In my experience range checks did affect the speed, but range check alone may not be to blame. It might well be that code pieces became a tad bit larger than what a compiler would automatically inline, and those snow-balled. In case you have such a benchmark handy would appreciate a link 'cause fast is good, but fast and correct is way better.

bunderbunder 13y ago
If you're really in a position where you need to worry about performance down to the level of counting individual instructions then you probably shouldn't be relying on someone else to do your benchmarks for you, anyway.
- srean 13y ago
  Where did you get the "counting individual instructions" from ? I continue to remain willing to be convinced if someone provides the benchmarks, mine own turned out to be disappointing.