On 6/18/13 5:03 PM, Daniel Lee wrote:
> Can anyone show using O3 and no -g and no profiling that check_not_nan
> actually takes time? If not, I'd like to table
> the discussion and suggest we use error checking wherever appropriate.
I just closed the issue.
I was never suggesting to get rid of error checking! I just
suspected an issue with the check_not_nan() implementation.
I'll be more careful to measure functions
independently before submitting another issue based on
profiling an involved function. No idea why the profiler showed
so much time in is_nan().
I couldn't measure a difference (meaning that the between-run
differences were larger than the code differences) between:
1. stan::math::check_not_nan<double,double>("fun",x,"x");
2. if (x != x) return std::numeric_limits<double>::quiet_NaN();
The timing is also the same with x = NaN and x = 0.01.
I also couldn't measure a difference between clang++ and g++.
Then I thought it might all be branch prediction and then checked
every other iteration adding NaN and 0.01, which defeats branch
prediction. That did have an effect. It's about 5% slower under
g++ and 10% slower under clang++. (So in this case, there was
a difference between clang++ and g++.)
I'll append the test code.
- Bob
-------------------
#include <stan/math/error_handling/check_not_nan.hpp>
#include <iostream>
#include <limits>
inline double fun(double x) {
if (x != x) return std::numeric_limits<double>::quiet_NaN();
// stan::math::check_not_nan<double,double>("fun",x,"x");
return x;
}
int main() {
double outer_sum = 0;
for (int m = 0; m < 10000; ++m) {
double sum = 0;
for (int n = 0; n < 1000000; ++n)
sum += fun(std::numeric_limits<double>::quiet_NaN());
// sum += fun(0.001);
// sum += fun(n % 2 == 0 ? 0.01 : std::numeric_limits<double>::quiet_NaN());
outer_sum += sum;
}
std::cout << "outer_sum=" << outer_sum << std::endl;
}
------------------