
Renjin: a JVM-based interpreter for the R language - phillc73
http://www.renjin.org
======
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](https://github.com/graalvm/fastr)

~~~
peatmoss
One of the interesting things I note from the readme, is that they have an
implementation of Grid graphics. Grid is pretty awesome for lower level
graphics, and is part of the reason ggplot is able to be as good as it is.

Looking forward to poking around at their implementation. If it’s a JVM
friendly implementation, that could open up some nicer visualization options
from other languges like clojure, scala, etc.

~~~
mj_kallen
Indeed, they presented this at the last RIOT workshop in July [1] and it's a
great way to support graphics without dealing with the grDevices package from
GNU R.

[1] [https://youtu.be/otXTGBTb-3w?t=985](https://youtu.be/otXTGBTb-3w?t=985)

~~~
peatmoss
Oh cheers! Looking forward to watching that.

------
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.

~~~
baldfat
First thing I did was look at packages and see if tidyverse, purrr, lubridate,
stringr and feather. They are all there.

[http://packages.renjin.org/packages/search?q=tidyverse](http://packages.renjin.org/packages/search?q=tidyverse)

~~~
phillc73
Yes, but some of them aren't available yet, specifically dplyr:

[http://packages.renjin.org/package/org.renjin.cran/tidyverse](http://packages.renjin.org/package/org.renjin.cran/tidyverse)

------
haifeng
There is a java/scala project providing R like statistical computation:

[http://haifengl.github.io/smile/linear-
algebra.html](http://haifengl.github.io/smile/linear-algebra.html)

------
Annatar
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?

~~~
thebelal
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](https://github.com/wch/r-source) [1]:
[https://github.com/wch/r-source/tree/trunk/src/modules/lapac...](https://github.com/wch/r-source/tree/trunk/src/modules/lapack)

~~~
cat199
> however that is largely skewed by the included LAPACK code

which is where most of your number crunching will be happening..

------
stewbrew
IMHO the crucial question is whether users can use libraries that load native
libraries and/or make use of rcpp. The docs make me think it's not possible.

~~~
phillc73
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](http://packages.renjin.org/package/org.renjin.cran/Rcpp)

[2] [http://docs.renjin.org/en/latest/package/index.html#using-
re...](http://docs.renjin.org/en/latest/package/index.html#using-renjin-as-an-
r-package)

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

~~~
kprybol
Wasn’t that already possible via the rJava library?

~~~
michaelmior
True. Although Renjin seems like it provides a bit of a nicer interface in
some cases. (Disclaimer: not an R developer)

------
eggy
R's wealth of libraries and syntax was always appealing to me, so maybe now I
will look at how compatible and faster Renjin might be.

------
kazinator
> _Renjin allows the user to plugin best-of-class implementations of BLAS,
> LAPACK, and FFT,_

Makes sense. Why, if you want numerics that were traditionally written in
Fortran, of course you have to go to JVM. :)

------
Myrmornis
How does Renjin run the BLAS and LAPACK Fortean code, and the C code in R?

~~~
psk0
We transpile all C, C++, and Fortran code directly to Java-bytecode using our
open source tool called gcc-bridge
([https://github.com/bedatadriven/renjin/tree/master/tools/gcc...](https://github.com/bedatadriven/renjin/tree/master/tools/gcc-
bridge)). This is included as part of Renjin, but you can use it independently
as part of your project as well.

~~~
yazr
This is nice.

Does anyone know of a similar tool for c# ?

------
tranwen
Tried a few basic things, some of them did not work:

1\. x = rnorm(1000) 2\. plot(density(x)) --> not work 3\. stem(x) --> not work
4\. summary(x) --> works

For R data handling, I always use data.table for its efficiency and power.

1\. library(data.table) 2\. x = data.table(x=rnorm(1000)) --> not work > x =
data.table(x=rnorm(1000)) ERROR: Exception calling Calloccolwrapper :
Unimplemented GNU R API function 'DUPLICATE_ATTRIB'

~~~
kirillseva
Well supposedly you'd use native data.frame's if you're using a faster R
implementation.

However, I would agree with you that at this point in time it's fair to assume
that R is no longer a language in and of itself - it's more akin to a
collection of APIs around years of optimized C++ code, somewhat separated into
a few universes (bioinformatics, time series analysis with xtz, data.table
aficionados and tidyverse acolytes).

And thus making a faster R alternative should focus on 100% package
compatibility along with speeding up native R code. Renjin, pqR [1], et. al.
all seem to be compromises that work for some workflows but not all of them.

The project that I'm excited for is fastR [2] - bringing R, C, C++ and FORTRAN
code together into one Truffle/Graal environment would be absolutely huge for
this ecosystem.

However, I've tested fastR on my employer's [3] workflows and it does not work
yet.

[1] [http://www.pqr-project.org/](http://www.pqr-project.org/) [2]
[https://github.com/graalvm/fastr](https://github.com/graalvm/fastr) [3]
[http://syberia.io/](http://syberia.io/)

