应该嵌套mclapply调用吗？

Question

嵌套parallel::mclapply是个好主意吗？

require(parallel)
ans <- mclapply(1:3, function(x) mclapply(1:3, function(y) y * x))
unlist(ans)

产出：

[1] 1 2 3 2 4 6 3 6 9

所以它“起作用了”。但是，它是否被推荐用于真正的计算密集型任务，这些任务的数量超过了核心的数量？当这个被执行的时候发生了什么？多个叉子涉及更多的潜在浪费吗？mc.cores和mc.preschedule需要考虑什么？

编辑只是为了澄清其动机，通常通过分裂一维(例如，使用不同的核来处理n个不同年份的数据)来并行化，然后在这个分裂过程中出现另一种自然的拆分方式(例如，使用不同的核来计算不同函数中的每一个)。当m次n小于可用核总数时，上述嵌套看起来是合理的，至少在表面上是这样。

Answer 1

在下面的实验中，与嵌套并行执行相比，测试函数testfn()的并行执行速度更快：

library(parallel)
library(microbenchmark)
testfn <- function(x) rnorm(10000000)

microbenchmark('parallel'= o <- mclapply(1:8, testfn, mc.cores=4),
               'nested'  = o <- mclapply(1:2, function(x) mclapply(1:4, testfn, mc.cores=2), 
                                         mc.cores=2),
               times=10)
Unit: seconds
     expr      min       lq     mean   median       uq      max neval
 parallel 3.727131 3.756445 3.802470 3.815977 3.834144 3.890128    10
   nested 4.355846 4.372996 4.508291 4.453881 4.578837 4.863664    10

解释

R会话与四个R工作人员之间的通信似乎比R会话与两个工作人员之间的通信更有效，后者依次向其他两个工作人员分叉和通信。

替代

包foreach可以处理嵌套循环，这与嵌套的mclapply()调用非常接近；请参见vignette https://cran.r-project.org/web/packages/foreach/vignettes/nested.pdf。

(参数mc.preschedule的最佳设置取决于具体问题；请参见帮助页?mclapply。)