HenrikBengtsson
commented
8 years ago My reply turned out to be much longer than anticipated, but you're probably not the only wondering, so I figured it's worth be as explicit as possible.
There are a few things in play here that explains this, but the gist is:
the overhead of setting up an individual future, internal validation, and sending data back and forth between the main R session and the individual background worker is significantly larger than the time it takes to evaluation each R expression.
Another way to put it, there will always be a threshold where the overhead for parallelizing is greater than the speedup in time. This depends on what type of parallelization is done and how complex the computations are. Also, there are cases where one must parallelize by distributing compations to multiple computers due to memory constraints - in such cases the tradeoff of speed can still be worth it. This is not specific to futures, but to all type of parallelization.
With 1000 iterations and 4 background R worker sessions, a rough estimate is that it's worth parallelizing in this specific case if each iteration would take > 30ms to evaluate, e.g.
> system.time(for (i in 1:1000) { Sys.sleep(0.03); rnorm(i, mean = mu, sd = sigma) })
user system elapsed
0.204 0.052 30.499
> library("foreach")
> system.time(foreach(i = 1:1000) %do% { Sys.sleep(0.03); rnorm(i, mean = mu, sd = sigma) })
user system elapsed
1.520 0.044 31.875
> library("doFuture")
> registerDoFuture()
> plan(multisession, workers = 4L)
> system.time(foreach(i = 1:1000) %dopar% { Sys.sleep(0.03); rnorm(i, mean = mu, sd = sigma) })
user system elapsed
12.280 0.532 32.008 In detail, here is an outline what is happening behind the scene:
- When the very first future is created, which here happens in the first iteration of
foreach(), that is also when the four background "multisession" R workers are launched. This adds a little bit of startup overhead. - The 4 workers are only created once and then reused throughout your R session or until you change strategy with
plan(). So, launching multisession workers (or cluster workers) in general is a one-time thing. This should answer your question in Issue #5. - There are 1000 iterations, which results in 1000 futures, which results in 1000 "jobs" being sent to the 4 workers. Each worker only process 1 future at the time, so if the first four jobs wouldn't be ready when the 5th is created, the the main R process will block until a worker is available again.
- When a future is created, the default is that global variables are automatically identified through static code inspect of the expression. In this case, the globals are iterator variable
i, and variablesmuandsigma. In each iteration these are exported to the worker. In addition to this, packages that needs to be attached for functions to be available are also attached. In this case it is the functionstats::rnorm()that needs to be available, which is whystatsis attached. This also happens explicitly for each future / each iteration.- Comment: Yes, correct, since variable
muandsigmanever change, we could technically only export them once to the workers instead of doing it once per iteration. This is something I'd like it do be able to do in the future, but it requires quite a bit of work to get it right in all use cases. For instance, we must make sure there is no risk for such global "constants" to actually change between iterations (in the main R session or in the workers). The same goes for attaching packages - they could ideally be attached once per worker. On the other hand, the added overhead for doing once per iteration shouldn't be that high.
- Comment: Yes, correct, since variable
- The above describes the overhead from using futures per se. There is also overhead added by the
foreach::foreach()framework. Which you can see from the below somewhat naive benchmarking code.
library("doFuture")
## Globals
mu <- 1.0
sigma <- 2.0
t <- system.time(y <- foreach(i = 1:1000) %do% { rnorm(i, mean = mu, sd = sigma) })
print(t)
## user system elapsed
## 0.312 0.004 0.315
registerDoSEQ()
t <- system.time(y <- foreach(i = 1:1000) %dopar% { rnorm(i, mean = mu, sd = sigma) })
print(t)
## user system elapsed
## 0.364 0.000 0.364
library("doParallel")
cl <- parallel::makeCluster(4L)
registerDoParallel(cl)
t <- system.time(y <- foreach(i = 1:1000) %dopar% { rnorm(i, mean = mu, sd = sigma) })
print(t)
## user system elapsed
## 0.532 0.028 10.523
parallel::stopCluster(cl)
registerDoFuture()
plan(eager)
t <- system.time(y <- foreach(i = 1:1000) %dopar% { rnorm(i, mean = mu, sd = sigma) })
print(t)
## user system elapsed
## 2.808 0.012 2.821
registerDoFuture()
plan(multisession)
t <- system.time(y <- foreach(i = 1:1000) %dopar% { rnorm(i, mean = mu, sd = sigma) })
print(t)
## user system elapsed
## 9.492 0.520 21.965
## Whatabout a simple for loop?
t <- system.time({
y <- list()
for(i in 1:1000) y[[i]] <- { rnorm(i, mean = mu, sd = sigma) }
})
print(t)
## user system elapsed
## 0.052 0.000 0.051
## What is the overhead if we use plain sequential futures?
library("listenv")
plan(eager)
t <- system.time({
y <- listenv()
for(i in 1:1000) y[[i]] %<-% { rnorm(i, mean = mu, sd = sigma) }
y <- as.list(y)
})
print(t)
## user system elapsed
## 1.852 0.000 1.853
## Whatabout multisession futures?
plan(multisession, workers = 4L)
t <- system.time({
y <- listenv()
for(i in 1:1000) y[[i]] %<-% { rnorm(i, mean = mu, sd = sigma) }
y <- as.list(y)
})
print(t)
## user system elapsed
## 8.932 0.424 21.872 In summary, yes, there's a goal to lower overhead further both in the core future package, but also the doFuture package. But regardless, it will never be worth parallelizing very simple R expression that are finishes quickly. Of course, one can always parallelize in chunks and thereby lower the total parallelization overhead - the foreach package provides some of this via the use of different iterators, cf. help("foreach", package="foreach").
Hope this helps
PS. I think you meant plan(multisession, workers = 4) without () because the latter gives an immediate error.
instantkaffee
paullevchuk
I do not see a any speed improvement when using
doFuture. Below code is much slower when usingplan(multisession). Do I oversee something ?