Posted on Categories OpinionTags , , 1 Comment on Not Always C++’s Fault

Not Always C++’s Fault

From the recent “Staged Install” article:

Incidentally, there were just two distinct (very long) lists of methods in the warnings across all installed packages in my run, but repeated for many packages. It turned out that they were lists of exported methods from dplyr and rlang packages. These two packages take very long to install due to C++ code compilation.

Technical point.

While dplyr indeed uses C++ (via Rcpp), rlang appears to currently be a C-package. So any problems associated with rlang are probably not due to C++ or Rcpp. Similarly other tidyverse packages such as purrr and tibble are currently C packages. I think purrr once used C++, but do not know about the others.

Posted on Categories Opinion, ProgrammingTags , ,

Why RcppDynProg is Written in C++

The (matter of opinion) claim:

“When the use of C++ is very limited and easy to avoid, perhaps it is the best option to do that […]”

(source discussed here)

got me thinking: does our own RcppDynProg package actually use C++ in a significant way? Could/should I port it to C? Am I informed enough to use something as complicated as C++ correctly?

Continue reading Why RcppDynProg is Written in C++

Posted on Categories OpinionTags , 6 Comments on C++ is Often Used in R Packages

C++ is Often Used in R Packages

The recent r-project article “Use of C++ in Packages” stated as its own summary of recommendation:

don’t use C++ to interface with R.

A careful reading of the article exposes at least two possible meanings of this:

  1. Don’t use C++ to directly call R or directly manipulate R structures. A technical point directly argued (for right or wrong) in the article.
  2. Don’t use C++/Rcpp to write R packages. A point implicit in the article. C++ and Rcpp (a package designed to allow the use of C++ from R) are not the same thing, but both are mentioned in the note.

One could claim the article is “all about point 1, which we can argue on its technical merits.” The technicalities involve discussion of C‘s setjmp/longjmp and how this differs from C++‘s treatment of RAII, destructors, and exceptions.

(edit: It has been pointed out to me that as there is no C++ interface to R that the point-1 interpretation is in some sense not technically possible. All C++ is in some sense forced to go through the C interface. Yes things can go wrong, but in strict technical sense you can’t directly “use C++ to interface with R“, C++ calls .C() or .Call() just as C does.)

However, in my opinion the overall tone of the article unfortunately reads as being about point 2. In fact after multiple readings of the article I remain uncomfortable saying if the article is in fact attempting to make point 2 or attempting to avoid point 2. Statements such as “Packages that are already using C++ would best be carefully reviewed and fixed by their authors” seem to accuse all existing C++ packages. But statements such as “one could use some of the tricks I’ve described here” seem to imply there are in fact correct ways to interface C++ with R (which for all we know, many C++ packages may already be using).

I think a point 2 interpretation of the article does the R community a disservice. So I hope the note is not in fact about point 2. And if it isn’t about point 2, I wish that had been stronger emphasized and made clearer.

For context Rcpp is the most popular package on CRAN. Based on CRAN data downloaded 2019/03/31: Rcpp is directly used in 1605 CRAN packages (or about 11% of CRAN packages), and indirectly used (brought in through Import/Depends/LinkingTo) by 6337 packages (or about 45% of CRAN packages). It has the highest reach of any CRAN package under each of those measures (calculation shared here), and even under a pagerank style measure.

Rcpp is something R users should be appreciative of and grateful for. Rcpp should not become the subject of fear, uncertainty, and doubt.

I apologize if I am merely criticizing my own mis-reading of the note. However, others have also written about discomfort with this note, and the original note comes from a position of authority (so does have a greater responsibility to be fairly careful in how it might be plausibly read).

Posted on Categories Coding, Opinion, TutorialsTags , , , 7 Comments on Timing the Same Algorithm in R, Python, and C++

Timing the Same Algorithm in R, Python, and C++

While developing the RcppDynProg R package I took a little extra time to port the core algorithm from C++ to both R and Python.

This means I can time the exact same algorithm implemented nearly identically in each of these three languages. So I can extract some comparative “apples to apples” timings. Please read on for a summary of the results.

Continue reading Timing the Same Algorithm in R, Python, and C++