Comments on: Calling C++ from R using Rcpp

By: James

James — Mon, 01 Jun 2015 21:54:36 +0000

replications=rep(1,0,1) – this is a misleading part of the whole article, could you please change it to sth. else?

Also, i didn’t find the parad version faster than x/y – curious whether we are comparing 8cpus vs. 1 cpu?

By: admin

admin — Sun, 13 Oct 2013 15:19:22 +0000

Cheers 🙂 I have another example of using Rcpp here:
http://www.lindonslog.com/programming/parallel-random-number-generation-trng/

By: Raffael Vogler

Raffael Vogler — Sun, 13 Oct 2013 15:11:17 +0000

I think I get your point! Right now I really don’t have any serious experience with either way. But I will come back to this topic when I do. Of course any introductory articles on your blog on .C/.Call/Rcpp are highly welcome – I guess I am not the only one who would appreciate it!

By: admin

admin — Sun, 13 Oct 2013 15:01:12 +0000

I recall that their main selling point was that using “.Call()” really obfuscates the code because you have to “protect” and “unprotect” variables all the time because otherwise the R garbage collector may delete variables that you are using. I tried “.Call()” once and Rcpp is certainly a large improvement on this because it takes care of the protection for you. I use “.C()”, however, which involves some copying of the variables to C++ and then you don’t need to worry about the garbage collector. Most people really object to this transfer “overhead”, but if I am porting something from R to C++ then it would necessarily be something very computationally intensive in the first place, in which case the transfer overhead is negligible in comparison. I guess the people who object to the transfer overhead are those who just want to port a small block of code like a nested for loop, in which case the objection is reasonable. This is what I mean by Rcpp is meant for R-users as opposed to C++ users. I started writing a package for R which I wanted to be as fast as possible, which was the reason I started looking in to this. The only interaction I wanted with R was receiving the initial data and sending the final results – so having nothing to do with R in the mean time, so .C() works just fine for me. Plus with .C() you use your regular C++ datatypes and expressions without worrying about converting them with as.something(). .C() just allows me to code C++ without getting in the way with strange SEXP datatypes and other things. I think you will find that most packages coded in C/C++ with just use .C(). That’s my take on it anyway.

By: Raffael Vogler

Raffael Vogler — Sun, 13 Oct 2013 09:25:15 +0000

I mean in that sense it would be the choice for as I am an R-user who would just consider resorting to C++ for specific purposes. But you also say that you would rather use “.C” than Rcpp. How is that? There is a very interesting SO thread between Hadley, Dirk and Romain and they (Dirk and Romain) make good points in favor of Rcpp. I would like to know more about your take on this. – your command of German is pretty good btw!

By: admin

admin — Sun, 13 Oct 2013 01:20:30 +0000

schön dass es dir gefällt, Raffael. Ich muss aber zugeben dass ich es halt einfacher finde “.C” zu benutzen als Rcpp. Meine Meinung nach ist Rcpp eher für R-Nutzern als C++ Nutzern zugedacht…

By: Raffael Vogler

Raffael Vogler — Fri, 11 Oct 2013 19:20:42 +0000

I very much enjoyed reading your article. It is a long time ago that I programmed C++ the last time but it looks still familiar. Given the lack of Windows-compatible packages for utilizing my GPU I am eager to give CUDA a try using Rcpp.