[FR] Allow rfun to optionally run in parallel over iters

[SteveBronder]

trafficstars

Looking at the code for rfun and looking at the future dev guide I think that that we could allow users to optionally specify whether the rfun should be allowed to run over iterations in parallel.

plain(multicore)
my_fun = function(x, y) {
  return x + y
}
# parallel_args is a list of args for `future.mapply`
my_fun_rvar = rfun(my_fun, c("x", "y"), parallel = TRUE, parallel_args = list(...))

plain(multicore)
x = # ... 
y = # ...
z = my_fun_rvar(x, y)

I think we would just have to modify the signature like

rfun <- function (.f, rvar_args = NULL, ndraws = NULL, parallel = FALSE, parallel_args = list()) 

Then in the code when we call mapply we call future.mapply. I think for the parallel_args we would need to wrap future.mapply in a do.call as well but I can't remember rn

[mjskay]

This seems like a nice idea to me.

I know we ended up deciding against using {future} for other parallel stuff awhile back, though personally I am leaning more towards using it now (I don't know how @paul-buerkner or @jgabry feel). It has the significant advantage that users can easily select how they want work to be parallelized, and (slightly selfishly) I think it tends to work better on Windows than other options. But if we wanted to use {future} here it would be a bit inconsistent with how parallelism is implemented in summarise_draws(), so I think we'd want to either follow the pattern of summarise_draws() or re-open the discussion of how to do parallelism in {posterior} and whether we want to support {future} in summarise_draws().

[paul-buerkner]

I understand and share the motivation for future. Personally, I am happy to reconsider the parallelization also for summarise_draws() if we see clear advantages of using future in general and of using only a single parallelization interface across the package.

[SteveBronder]

tbc I'm fine with whatever parallel scheme is best. I chose future only because I tend to use it irl and it's nice but if we want something lower level I'm fine with that as well

[jgabry]

I understand and share the motivation for future. Personally, I am happy to reconsider the parallelization also for summarise_draws() if we see clear advantages of using future in general and of using only a single parallelization interface across the package.

Yeah I agree