[Rcpp-devel] Rcpp ISNAN slower than C ISNAN?
Johannes Kruisselbrink
johannes at kruisselbrink.eu
Wed Dec 14 20:23:44 CET 2016
> Take care to distinguish the R-core ISNAN macro, the R_IsNaN function,
> and the Rcpp::isNaN template function. Asides from sugar-stuff, all
> the examples discussed here so far address the performance of R-core
> ISNAN, given doubles that are accessed via Rcpp, correct?
Good point. Actually, I didn't even realize there were so many is-nan
functions to choose from. But indeed, we used the R-core ISNAN function
on doubles accessed via Rcpp.
> "Currently in C code ISNAN is a macro calling isnan. (Since this gives
> problems on some C++ systems, if the R headers is called from C++ code
> a function call is used.) "
> http://www.hep.by/gnu/r-patched/r-exts/R-exts_133.html
>
> Definitions from the horse's mouth:
> https://github.com/wch/r-source/blob/trunk/src/include/R_ext/Arith.h#L66
This was also pointed out by Bill Dunlap and indeed seems to be the
explanation for the difference. Very unfortunate, because it was our
most preferred ISNAN function. Seems that those "some C++ systems" ruin
it for others.
> Based on the above, I added permutations to a *very* minimal test (no
> return val, etc) that include Romain's suggestion:
> https://github.com/helmingstay/rcpp-timings/tree/master/minimal
> ## source('benchmarks.r')
>
> I see that:
> A) the sugar expression in slow
> B) based on timings, ISNAN appears to call R_isnancpp, which is slow
> C) std::count_if yields a modest improvement given B)
> D) Using an inline function matching the definintion of ISNAN used in
> a C envir [i.e., "isnan(xx)!=0", using math.h] appears to incur no
> cost at all (example CountNans_expr)
Wow, thank you for the thorough comparison. I ran some tests myself
based on your code. It seems that I cannot get the "CountNans_expr"
version to compile, any ideas? Same problem with the Rcpp sugar isnan
version.
The std::isnan version, however, does work and, on my machine, actually
outperforms the call function. So performance-wise this is a very
interesting candidate. How safe is it to use this function? Would that
also be a "driving-without-seatbelts" equivalent?
More information about the Rcpp-devel
mailing list