时间戳

首页 > 解决方案 > 增加 mc.cores 超出逻辑核心数

r - 增加 mc.cores 超出逻辑核心数

问题描述

玩弄 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

我还在一个更现实的例子中尝试了这一点，即接近我想要并行化的真实场景：这也没有导致任何问题。

在 /tutorials on 的文档中parallel::mclapply，我找不到任何mc.cores > detectCores()选择的示例，而且很可能有一个很好的理由。

有人可以解释这种做法有什么问题吗？在某些情况下是否合理，例如当内存需求不是问题时？

标签： rparallel-processingmclapply

解决方案

我有时会mc.cores > detectCores()用来限制内存使用。如果您将一个作业分成 10 个部分并使用 和 处理它们mclapply，mc.preschedule=F则每个核心一次只能处理 10% 的作业。例如，如果mc.cores设置为两个，则其他 8 个“节点”必须等到一个部分完成后才能开始新的部分。如果您遇到内存问题并希望防止每个循环超出其处理能力，这可能是可取的。

推荐阅读