> 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. :)
Renjin: a JVM-based interpreter for the R language
31–37 of 37 posts
Re: Renjin: a JVM-based interpreter for the R language
#32[deleted]
Re: Renjin: a JVM-based interpreter for the R language
#33Earlier quoted context omitted.
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.
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
Oh cheers! Looking forward to watching that.
Re: Renjin: a JVM-based interpreter for the R language
#34I 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]: ht…
> however that is largely skewed by the included LAPACK code
which is where most of your number crunching will be happening..
Re: Renjin: a JVM-based interpreter for the R language
#35How does Renjin run the BLAS and LAPACK Fortean code, and the C code in R?
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... ). This is included as part of Renjin, but you can use it independently as part of your project as well.
This is nice.
Does anyone know of a similar tool for c# ?
Re: Renjin: a JVM-based interpreter for the R language
#36Tried 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_ATT…
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/ [2] https://github.com/graalvm/fastr [3] http://syberia.io/
Re: Renjin: a JVM-based interpreter for the R language
#37Earlier quoted context omitted.
“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…
that's a fairly toxic and silly attitude towards a free software project. Don't like it - don't use it. I personally think it's great that there are people who are working on making R faster/better/popular, even though I may disagree with the methods they've chosen to achieve those goals.
I wish it were toxic but it isn’t - Java is still around, so software like Renjin gets written. If my attitude were toxic to Java, Renjin wouldn’t exist.