2

among the projects that aim to accelerate the R language, FastR that currently uses version 3.5.1 of the R language with GraalVM is the one seems to me to be more developed and compatible with the most recent version of the R.

Would anyone know if there is any way to integrate FastR with RStudio?

GraalVM + R (FastR): https://www.graalvm.org/docs/reference-manual/languages/r/.

Steves
  • 2,798
  • 21
  • 21
Pedro Rafael
  • 492
  • 4
  • 11

3 Answers3

3

At this point, RStudio does not support FastR. The problem is that RStudio uses some internal implementation details of GNU-R and it is difficult for FastR to emulate those properly, but we plan to support this "API" eventually.

You can use FastR from the GraalVM plugin for Visual Studio Code. It also supports debugging and the R support is based on this R Visual Studio code plugin.

Another possibility is to use FastR from GNU-R via the PSOCK cluster using the fastRCluster package, which can be installed (e.g. in RStudio) using:

devtools::install_github('oracle/fastr/com.oracle.truffle.r.pkgs/fastRCluster')

you can then use ?fastRCluster to learn more about it.

Steves
  • 2,798
  • 21
  • 21
  • One thing I noticed is that FastR does not use OpenBLAS by default. Maybe this could be set by default since BLAS is rather inefficient when compared to OpenBLAS. – Pedro Rafael Apr 17 '19 at 17:44
  • I tried point to the FastR from GraalVM through a symbolic link and I'm getting `This site can't be reached. 127.0.0.1 refused to connect`. I found that, when starting, "RStudio use a localhost connection to link your R session with the RStudio IDE". You know if this could be related to what you mentioned on your answer or if it is caused by another reason? – Hemerson Tacon Aug 27 '19 at 14:35
  • 1
    @HemersonTacon RStudio uses two independent processes: one shows you the UI and the other actually runs R via the [R embedding API](https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Embedding-R-under-Unix_002dalikes). FastR implements this API, but it is not fully working yet. If you wanted to try this, you'd need to compile RStudio with GNU-R replaced for FastR (I can give you more details should you be interested in pursuing this further). – Steves Aug 28 '19 at 12:42
  • Glad to know this. Can you please give me more details? – Hemerson Tacon Aug 28 '19 at 13:21
  • 1
    Basically, you'd follow [RStudio building from source](https://github.com/rstudio/rstudio/blob/master/INSTALL) documentation for building it in the server configuration, but when running `CMake` you pass additional option `-DCMAKE_PREFIX_PATH=/path/to/fastr/build`. Then when you start `rsession` include FastR's `bin` directory in `$PATH` and also export `R_HOME` pointing to FastR home. You need a dev build of FastR for this. The main thing is that `rsession` executable should be linked against FastR's `libR.so`. Note that `rsession` will going to fail, because of the mentioned issues in FastR – Steves Aug 28 '19 at 13:51
  • 1
    @HemersonTacon if you manage to make any progress on this, please share your findings on FastR GitHub :-) – Steves Aug 28 '19 at 13:52
2

The problem can easily be solved by creating a symbolic link to the OpenBLAS library I compiled and on my machine it is located in the /opt/OpenBLAS/lib directory. nside the /usr/lib/jvm/java-8-graal/jre/languages/R/lib directory, I did:

sudo mv libRblas.so libRblas.so.keep
sudo ln -s /opt/OpenBLAS/lib/libopenblas_haswellp-r0.3.5.so libRblas.so

R + GraalVM (FastR):

   user  system elapsed 
 98.425   2.393  38.324
Pedro Rafael
  • 492
  • 4
  • 11
  • 1
    Thank you for sharing this. The number may improve a little bit if you execute the benchmark second time as FastR compiles the code dynamically while it is running. However, this is an example of a benchmark, where FastR cannot gain a lot because in the end both FastR and GNU-R execute the same algorithm from the BLAS library. – Steves Apr 18 '19 at 08:27
  • 1
    Exact. The examples execute C codes. The benchmark is close to Julia and R, since inv in Julia and solve in R are functions that imcoporate C codes. However, leaving default by OpenBLAS in fastR is something interesting. The Julia community lives comparing Julia with GNU R + BLAS while Julia uses LLVM and OpenBLAS. That is very unfair. Leaving OpenBLAS by default would be an important point since many R users would not understand that in this example the slowness is due to BLAS and not to GraalVM. Best regards. All the best for the project and success. Thank you. – Pedro Rafael Apr 18 '19 at 09:49
1

One thing I noticed is that FastR does not use OpenBLAS by default. Maybe this could be set by default since BLAS is rather inefficient when compared to OpenBLAS.

Consider the code below:

M <- matrix(runif(n = 5000^2, 0, 1), 5000, 5000)

inverse_loop <- function(matriz, n = 10){
  for (i in 1:n){
    solve(matriz)
  }
}

system.time(inverse_loop(M))

Note: It is a simple code that only makes repeated inversions of a large matrix.

Benchmarks

GNU R with OPenBLAS:

> sessionInfo()
R version 3.5.3 (2019-03-11)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Manjaro Linux

Matrix products: default
BLAS/LAPACK: /opt/OpenBLAS/lib/libopenblas_haswellp-r0.3.5.so

Result:

[pedro@pedro-de Downloads]$ Rscript code.R 
     user    system   elapsed
   98.037     6.225    30.743

R + GraalVM (FastR):

> sessionInfo()
FastR version 3.5.1 (2018-07-02)
Platform: x86_64-unknown-linux-gnu (64-bit)
Running under: Manjaro Linux

Matrix products: NULL
BLAS: /usr/lib/jvm/java-8-graal/jre/languages/R/lib/libRblas.so
LAPACK: /usr/lib/jvm/java-8-graal/jre/languages/R/lib/libRlapack.so

Result:

./Rscript /home/pedro/Downloads/code.R

   user  system elapsed 
910.810   6.393 928.996
Pedro Rafael
  • 492
  • 4
  • 11