-3

I have been using R for my research in corporate finance and asset pricing, and really like it due to my background in Math and Statistics. Until now, I encountered 2 main constrains in R. The first one is handling big data files, but I have kind of circumvented it by combining R with PostgreSQL and Spark, and I believe I can get more RAM from high performance computer or AWS cloud in the future. The second constrain is executing speed (important for handling tick by tick security quote data), and I was recommended that Julia has huge speed advantage over R. My question is that since Rcpp offers a really fast execution, does the speed advantage of Julia still hold? I am considering if I should learn Julia.

In addition, R provides a perfect database connection with WRDS, Quandl, TrueFX, and TAQ, and I am really used to Hadley Wickham style data cleaning. As a academic guy, I kind of like the fact that R has support from peer review journals like Journal of Stat Software. I will try Julia and see how it works. Thanks for all the answers and comments!

Tuan Le
  • 97
  • 1
  • 7
  • 3
    This question is a bit too generic. However, you can have a look at this paper: http://economics.sas.upenn.edu/~jesusfv/comparison_languages.pdf. It compares the performance of several programming languages (including Rcpp and Julia). – merch Apr 24 '17 at 22:52
  • @merch Thanks so much. Is Rcpp the fastest approach in R environment? – Tuan Le Apr 24 '17 at 23:02
  • 2
    That language comparison was from the stone ages of Julia (v0.2). I think the better thing to notice is that type-stable Julia is code is just as fast as clang compiled C++. In fact, it compiles to essentially the same code, so there isn't a difference in speed. The differences in speed here would found to be due to the different system math library that was used (the `log` function) and the fact that early Julia didn't default to -O3 compilation (which it now does). – Chris Rackauckas Apr 24 '17 at 23:04
  • @TuanLe I am sure other people may reply better than me on this. However, this second question about Rcpp is too broad. Generally, this kind of questions may generate a proliferation of comments based on *opinions*. Why don't you edit your question and ask about a specific problem on your field where speed is required - maybe with an example in Rcpp? – merch Apr 24 '17 at 23:10
  • @ChrisRackauckas it is an old comparison, but the field in which the languages have been tested is similar to the one of the OP. – merch Apr 24 '17 at 23:11

1 Answers1

7

Rcpp and Julia will get you to the same place in the end performance-wise. In fact, type-stable Julia will compile to the essentially the same LLVM IR as clang compiled C++. Design-wise there's nothing that stops it from being the same (in the type-stable case), other than a few missing optimizations because the language is young (example, @fastmath doesn't add FMA by default, so you'd have to add FMA calls yourself, whereas I believe C++ compiled with fastmath will FMA). But you can play around check that @code_llvm and @code_native outputs the same code, given type-stability.

However, Rcpp would require that you write a bunch of C++ code and test/maintain that code along with your R code. C/C++ is much lower level and can be more difficult to maintain (the "two language problem"). If you choose to go with Julia, you can write it all in Julia. That's the main difference.

(As for the whole "Julia is 2x slower than C", should probably be mentioned here. Normally it's due to having small parts of type-unstable code, not turning off array bounds checking with @inbounds (the language comparison from the comments notably doesn't do this, which can cause a pretty large difference in a tight loop), and relying on vectorization styles (a la R/MATLAB/Python). The last part is much better in Julia v0.6, but it will always have a small cost over looping. In the end, it's opt-in/opt-out choices for concise code and additional safety checks that causes the difference.)

Community
  • 1
  • 1
Chris Rackauckas
  • 18,645
  • 3
  • 50
  • 81