Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Renjin: a JVM-based interpreter for the R language

renjin.org

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Renjin: a JVM-based interpreter for the R language

#11

Post by mwexler »

Annatar wrote: post #9
sorokod wrote: post #6

Earlier quoted context omitted.

From the documentation [1]: "As a service, BeDataDriven provides a repository with all CRAN (the Comprehensive R Archive Network) and BioConductor packages at http://packages.renjin.org . The packages in this repository are built and packaged for use with Renjin. Not all packages can be built for Renjin so please consult the repository to see if your favorite package is available for Renjin." [1] http://docs.renjin.o…

Yes. Renjin isn’t even a complete implementation of R and I don’t believe that a Java JIT will ever beat Fortran in performance. I’d sure like to see some evidence of JIT R beating the Fortran implementation. And then there is the memory inefficiency of Java. So again I ask: why?

Because there is value in having a completely jvm stack in some places. Sometimes performance takes a back seat to consistency. It may not be right, but that's the way it is in some orgs.

Re: Renjin: a JVM-based interpreter for the R language

#12

Post by Insanity »

Annatar wrote: post #8

I build and maintain the R stack in my organization. A good portion of the R core is written in Fortran for maximum performance and efficiency; the rest is in C and C++. Why would I want an interpreted, just-in-time, garbage collected version of R in a JVM when I can run at full speed on the real thing?

I suppose their reasons are here: http://www.renjin.org/about.html

I've only used R for a short time, so I can't comment on it myself.

Re: Renjin: a JVM-based interpreter for the R language

#13

Post by acaloiar »

Annatar wrote: post #9
sorokod wrote: post #6

Earlier quoted context omitted.

From the documentation [1]: "As a service, BeDataDriven provides a repository with all CRAN (the Comprehensive R Archive Network) and BioConductor packages at http://packages.renjin.org . The packages in this repository are built and packaged for use with Renjin. Not all packages can be built for Renjin so please consult the repository to see if your favorite package is available for Renjin." [1] http://docs.renjin.o…

Yes. Renjin isn’t even a complete implementation of R and I don’t believe that a Java JIT will ever beat Fortran in performance. I’d sure like to see some evidence of JIT R beating the Fortran implementation. And then there is the memory inefficiency of Java. So again I ask: why?

When I was implementing Renjin's PRNG based on GNR R's, I read a fair amount of GNU R code. I think it goes without saying that C and Fortran perform well. However, I do believe that R's flexibility as a language comes at a performance cost. The implementation of that flexibility is not always done in an efficient manner; and as a result performance suffers. I.e. R is not particular performant in certain circumstances despite being largely implemented in C and Fortran. I only have anecdote to offer in this regard, but it is worth considering that GNU R's good performance is not a foregone conclusion.

Re: Renjin: a JVM-based interpreter for the R language

#14

Post by Annatar »

Insanity wrote: post #12
Annatar wrote: post #8

I build and maintain the R stack in my organization. A good portion of the R core is written in Fortran for maximum performance and efficiency; the rest is in C and C++. Why would I want an interpreted, just-in-time, garbage collected version of R in a JVM when I can run at full speed on the real thing?

I suppose their reasons are here: http://www.renjin.org/about.html I've only used R for a short time, so I can't comment on it myself.

“R has been traditionally limited by the need to fit data sets into memory, and working with even modest sets of data can quickly exhaust memory due to historical limitations in GNU R interpreter’s implementation.”

I see that the propaganda machine never rests, no matter which language. Either that, or they haven’t heard of Vertica’s R, which is excellent and counters these claims.

The rest with the “fragmentation of R” is a poor marketing tack: people who run R are perfectly capable of thinking with their own brains, thank you very much; Renjin has no place patronizing. We’re not sheep.

Re: Renjin: a JVM-based interpreter for the R language

#15

Post by ianopolous »

FastR [1], an R implementation for the JVM using Truffle aims to be both fast and compatible, including C and fortran calls from R using Truffle's polyglot framework.

The thing that makes this even more awesome is inter language optimization - inline your C code into your R code at runtime, which can result in zero overhead inter language calls.

[1] https://github.com/graalvm/fastr

Re: Renjin: a JVM-based interpreter for the R language

#16

Post by kprybol »

michaelmior wrote: post #5
phillc73 wrote: post #3

Earlier quoted context omitted.

Regarding Rcpp, their package library says "A Renjin-specific version of this package is available."[1] Looks like Renjin can also be used from GNU R as an R package[2]. I'd assume any installed R package should also work in conjunction with it. Admittedly, I haven't tried Renjin, but only just found it and thought it was quite interesting. [1] http://packages.renjin.org/package/org.renjin.cran/Rcpp [2] http://docs.r…

Even just using Renjin to be able to access Java code within R seems super useful.

Wasn’t that already possible via the rJava library?

Re: Renjin: a JVM-based interpreter for the R language

#17

Post by phillc73 »

Annatar wrote: post #9
sorokod wrote: post #6

Earlier quoted context omitted.

From the documentation [1]: "As a service, BeDataDriven provides a repository with all CRAN (the Comprehensive R Archive Network) and BioConductor packages at http://packages.renjin.org . The packages in this repository are built and packaged for use with Renjin. Not all packages can be built for Renjin so please consult the repository to see if your favorite package is available for Renjin." [1] http://docs.renjin.o…

Yes. Renjin isn’t even a complete implementation of R and I don’t believe that a Java JIT will ever beat Fortran in performance. I’d sure like to see some evidence of JIT R beating the Fortran implementation. And then there is the memory inefficiency of Java. So again I ask: why?

Hadley's book, "Advanced R" has a specific performance related chapter[1]. As well as techniques to boost performance within R, there's a section on "Alternative R implementations," which says in part, "There are some exciting new implementations of R. While they all try to stick as closely as possible to the existing language definition, they improve speed by using ideas from modern interpreter design." Renjin is listed in this section.

While I don't have direct experience of Renjin, or any other alternative R interpreters, I'm inclined to believe Hadley has and if he believes they improve speed, I'll take him at his word.

[1] http://adv-r.had.co.nz/Performance.html

Re: Renjin: a JVM-based interpreter for the R language

#18

Post by mj_kallen »

Annatar wrote: post #8

I build and maintain the R stack in my organization. A good portion of the R core is written in Fortran for maximum performance and efficiency; the rest is in C and C++. Why would I want an interpreted, just-in-time, garbage collected version of R in a JVM when I can run at full speed on the real thing?

You certainly don't have to use it. One of the goals we had when we created Renjin was to keep it pure Java. Even the packages with native code are transpiled to pure Java bytecode so you can use an R interpreter in a JVM without interfacing to native code (e.g. using JNI) and this allows you to use the interpreter on an instance with one of the many Platform-as-a-Service providers like we do with Google App Engine.

Oh, GNU R is also garbage collected of course and compared to the JVM's garbage collector it is pretty primitive. This is an area where TIBCO have also improved their own R interpreter called TERR [1].

[1] http://www.edii.uclm.es/~useR-2013/slides/65.pdf

Re: Renjin: a JVM-based interpreter for the R language

#19

Post by peatmoss »

It's been a while since I've looked at Renjin. Last I looked, it was a worthy replacement for tasks that you'd do in base R, but the library story was incomplete.

Nowadays, my R usage has gone full tidyverse. Anyone know if dplyr and the gang work here? I know dplyr has a lot of C++ code, and don't know how well the "Renjin-specific" Rcpp interop story is.

Re: Renjin: a JVM-based interpreter for the R language

#20

Post by thebelal »

Annatar wrote: post #8

I build and maintain the R stack in my organization. A good portion of the R core is written in Fortran for maximum performance and efficiency; the rest is in C and C++. Why would I want an interpreted, just-in-time, garbage collected version of R in a JVM when I can run at full speed on the real thing?

While it is true that S was originally a macro layer around FORTRAN code R has always been primarily written in C. Very little of R core is in FORTRAN, and essentially none of it is C++.

The language statistics show a good deal of FORTRAN (%24.5) [0], however that is largely skewed by the included LAPACK code [1], which accounts for 221,921 / 259,773 lines of FORTRAN in R.

[0]: https://github.com/wch/r-source [1]: https://github.com/wch/r-source/tree/trunk/src/modules/lapac...

Post reply on HN