[Rcpp-devel] Rcpp speed

[Dirk Eddelbuettel]

On 21 December 2010 at 09:51, Gabor Grothendieck wrote:
| On Tue, Dec 21, 2010 at 9:39 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
| >
| > On 21 December 2010 at 09:15, Gabor Grothendieck wrote:
| > | Can anyone explain these results?   Rcpp takes 30% more time than R
| > | with 10 elements, the same time as R with 1000 elements and 7x as long
| > | with a million elements.  I would have expected the ratio to be
| > | highest for `10 elements since that would be dominated by the call
| > | sequence but its the other way around and it seems to get relatively
| > | less efficient as the size of the vector grows.
| >
| > Errr, these are _single expressions in the R parser_ !  So how could they be
| > faster in Rcpp when we have to do the extra marshalling of objects on the
| > heap, NA tests, exception handlings, etc pp ?  Did you seriously thing there
| > could be a gain?
| >
| > If you have a real task, time that.
| >
| > Do you recall the issue started by Radford Neal about curly or straight
| > paranthese?  When Christian Robert followed up and that whole thing became a
| > little blogging storm, I wrote an ad-hoc post ... demonstrating an 80-fold
| > speed increase with Rcpp.  That was in September, and be we may well have got
| > faster since as a number of tweaks went into Rcpp.
| >
| > In any event, the aforementioned blog post is
| >
| > http://dirk.eddelbuettel.com/blog/2010/09/07#straight_curly_or_compiled
| >
| > Otherwise, thanks for being empirical and posting replicable code using
| > inline and rbenchmark. That is the right idea. But I fear you started to
| > measure the wrong question here.
| 
| My question was not why Rcpp was slower.
| Also posted link does not use sugar.
| 
| My question was why the relative speed did not improve as the size
| increased but instead got worse.  Does using sugar mean that it just
| gets me back to the speed of R or worse?

Gabor, please rethink the point about expressions versus functions calls. 

Here is a version with three alternatives: R expression, R function, Rcpp
function.  Once you actually compare _function calls_ the result is not that
different, and if anything, slanted ever so slightly in our favour:

R> require(inline)
R> funRcpp <- cxxfunction(signature(x="numeric", y="numeric"),
+                        body = 'NumericVector xx(x);
+                                NumericVector yy(y);
+                                NumericVector zz = xx + yy;
+                                return( zz );',
+                        plugin="Rcpp")
x <- 1:3
y <- 10 * x
funR <- function(x, y) {
R> R> R> +     z <- x + y
+     return(z)
+ }
R> stopifnot(identical(funR(x, y), funRcpp(x, y)))
R> library(rbenchmark)
R> x <- 1:10
R> benchmark(replications = 10000,
+           R = x + x, Rfun = funR(x, x), Rcpp = funRcpp(x, x))
  test replications elapsed relative user.self sys.self user.child sys.child
1    R        10000   0.042   1.0000      0.05        0          0         0
3 Rcpp        10000   0.056   1.3333      0.05        0          0         0
2 Rfun        10000   0.057   1.3571      0.05        0          0         0
R> 

Sugar makes to claim of rewriting the R expression parser.  Rather, it aims
to make C++ code more productive by allowing for richer expressions.

Cheers, Dirk


-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com