4 ms·

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 evide

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?

mwexler 9y ago
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.
acaloiar 9y ago
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.
phillc73 9y ago
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 http://adv-r.had.co.nz/Performance.html

mwexler 9y ago

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.

acaloiar 9y ago

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.

phillc73 9y ago

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 http://adv-r.had.co.nz/Performance.html