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.
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.
Comments
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.
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.
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.