使用 R 函数 parallel::mclapply
,我发现参数 mc.cores
可以选择大于逻辑核心的数量(如 parallel::detectCores
),导致加速比逻辑核心的数量更大。这是一个最小的例子(对我来说,这适用于 MacOS 和 Linux):
sleepy <- function(i) {
start <- Sys.time()
Sys.sleep(i)
as.numeric(Sys.time() - start)
}
mc.cores <- 100L
ntasks <- 10000L
start <- Sys.time()
out <- parallel::mclapply(2/ntasks*runif(ntasks), sleepy, mc.cores = mc.cores)
real_duration <- as.numeric(Sys.time() - start)
cpu_duration <- sum(unlist(out))
data.frame(logical.cores = parallel::detectCores(),
mc.cores = mc.cores,
speedup = cpu_duration/real_duration)
## logical.cores mc.cores speedup
## 1 8 100 30.49574
我还在一个更现实的例子中尝试了这个,即接近我想要并行化的真实场景:这也没有导致任何问题。
在关于 parallel::mclapply
的文档/教程中,我找不到任何选择了 mc.cores > detectCores()
的示例,而且很可能是,这是有充分理由的。
有人可以解释一下这种做法有什么问题吗?在某些情况下是否合理,例如什么时候内存需求不是问题?
最佳答案
我有时使用 mc.cores > detectCores()
来限制内存使用。如果您将一个作业分成 10 个部分并使用 mclapply
和 mc.preschedule=F
处理它们,每个核心一次只会处理您的作业的 10%。例如,如果 mc.cores
设置为两个,则其他 8 个“节点”必须等到一个部分完成后再开始一个新的部分。如果您遇到内存问题并希望防止每个循环承担超出其处理能力的任务,这可能是可取的。
关于r - 将 mc.cores 增加到超出逻辑核心的数量,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/61115433/