3


I want to use rTorch in a furrr "loop". A minimal example seems to be:

library(rTorch)
torch_it <- function(i) {
  #.libPaths("/User/homes/mreichstein/.R_libs_macadamia4.0/")
  #require(rTorch)
  cat("torch is: "); print(torch)
  out  <- torch$tensor(1)
  out
}

library(furrr)
plan(multisession, workers=8) # this works with sequential or multicore
result <- future_map(1:5, torch_it)

I get as output:

torch is: <environment: 0x556b57f07990>
attr(,"class")
[1] "python.builtin.module" "python.builtin.object"
Error in torch$tensor(1) : attempt to apply non-function

When I use multicore or sequential I get the expected output:

torch is: Module(torch)
torch is: Module(torch)
torch is: Module(torch)
torch is: Module(torch)
torch is: Module(torch)

... and result is the expected list of tensors. Uncommenting the first lines in the function, assuming the new sessions "need this" did not help.

Update: I added torch <- import("torch") in the torch_it function. Then it runs without error, but the result I get is a list of empty pointers (?):

> result
[[1]]
<pointer: 0x0>
[[2]]
<pointer: 0x0>
[[3]]
<pointer: 0x0>
[[4]]
<pointer: 0x0>
[[5]]
<pointer: 0x0>

So, how do I properly link rTorch to each of the multisessions? Thanks in advance!

Info:

> R.version
               _                           
platform       x86_64-redhat-linux-gnu     
arch           x86_64                      
os             linux-gnu                   
system         x86_64, linux-gnu           
status                                     
major          4                           
minor          0.3                         
year           2020                        
month          10                          
day            10                          
svn rev        79318                       
language       R                           
version.string R version 4.0.3 (2020-10-10)
nickname       Bunny-Wunnies Freak Out
MR_MPI-BGC
  • 265
  • 3
  • 11
  • did you try `furrr_options(packages="torch")`? See [available options](https://davisvaughan.github.io/furrr/reference/furrr_options.html) – Waldi Feb 12 '21 at 09:27
  • I've never used torch by my guess is that it returns a C (or something not R) object wrapped in an R object (such as S4). So when returned from worker you get the R object but the reference to the backend object is dangling (it stayed in the worker memory). You should try to export or save this object (there should be a way) to a file or pure R object before returning from worker. – Billy34 Feb 12 '21 at 11:02
  • @Waldi, thanks for the hint! I tried this option, I get `torch is: ` and `Error in ...furrr_fn(...) : attempt to apply non-function` – MR_MPI-BGC Feb 12 '21 at 19:56
  • @Billy34, yes thanks also - I also suspect this, but I don't know how to keep the object linked. The use case does not allow writing it to a file, unfortunately. – MR_MPI-BGC Feb 12 '21 at 19:57
  • Looking at package tests, you might try to return `$numpy()` instead of ``. It seems to return the `numpy` array structure in R. You might also wrap a `as.vector` around it. I've not tried :-) – Billy34 Feb 12 '21 at 20:56
  • Thanks. yes, this is true - it works, but - sorry - I realize the use case was "too minimal", since the real one is more complicated, so that I really need to have access to PyTorch objects at the end. Btw I also wonder why the "multicore", i.e. forked session, does not parallelize. – MR_MPI-BGC Feb 13 '21 at 06:10
  • Forking is a lightweight parrallelization where sub process are merely a – Billy34 Feb 13 '21 at 16:49
  • Sorry ... Forking is a lightweight parallelization where sub processes are merely additional program pointer on the same code and share the same data existing before the fork. That means functions called should be re entrant (stateless and without side effect). Maybe the embedded python behind torch is not created in a proper way so as to be shared. Have also a look to (https://cran.r-project.org/web/packages/future/vignettes/future-4-non-exportable-objects.html) – Billy34 Feb 13 '21 at 16:58

0 Answers0