4 ms·

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

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?

kitd 9y ago
> interpreted, just-in-time, For clarification, the JVM JIT-compiles the most frequently used blocks of bytecode to machine code, so the bulk of the heavy lifting is not interpreted. The benefit of doing it this way is that compilation can be optimised based on the runtime-characteristics of the code, not compiler judgement. Cases of JVM code running faster than equivalent C/C++ code are not uncommon. Aside from that, access to Java libraries (eg for integration) may be important to some shops.
Insanity 9y ago
I suppose their reasons are here: http://www.renjin.org/about.html http://www.renjin.org/about.html I've only used R for a short time, so I can't comment on it myself.
- Annatar 9y ago
  “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.
  - kirillseva 9y ago
    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.
    - Annatar 9y ago
      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.
mj_kallen 9y ago
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 http://www.edii.uclm.es/~useR-2013/slides/65.pdf
thebelal 9y ago
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/lapack https://github.com/wch/r-source/tree/trunk/src/modules/lapac...
- cat199 9y ago
  > however that is largely skewed by the included LAPACK code which is where most of your number crunching will be happening..

kitd 9y ago

> interpreted, just-in-time, For clarification, the JVM JIT-compiles the most frequently used blocks of bytecode to machine code, so the bulk of the heavy lifting is not interpreted. The benefit of doing it this way is that compilation can be optimised based on the runtime-characteristics of the code, not compiler judgement. Cases of JVM code running faster than equivalent C/C++ code are not uncommon. Aside from that, access to Java libraries (eg for integration) may be important to some shops.

Insanity 9y ago

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

Annatar 9y ago
“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.
- kirillseva 9y ago
  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.
  - Annatar 9y ago
    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.

mj_kallen 9y ago

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 http://www.edii.uclm.es/~useR-2013/slides/65.pdf

thebelal 9y ago

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/lapack https://github.com/wch/r-source/tree/trunk/src/modules/lapac...

cat199 9y ago
> however that is largely skewed by the included LAPACK code which is where most of your number crunching will be happening..