看看未来的包(我是作者)。它提供了一个生态系统,将各种并行后端封装在一个统一的 API 中。在您已经拥有 SSH“批量”访问权限的四台多台 32 核机器的特定情况下,您可以将 4*32 工作人员指定为:
library("future")
## Set up 4 * 32 workers on four machines
machines <- c("node1", "node2", "node3", "node4")
workers <- rep(machines, each = 32L)
plan(cluster, workers = workers)
如果您的机器没有主机名,您可以指定它们的 IP 号码。
接下来,如果您喜欢使用foreach,请继续:
library("doFuture")
registerDoFuture()
y <- foreach(i = 1:100) %dopar% {
...
value
}
如果你更喜欢 lapply,你可以使用future.apply作为:
library("future.apply")
y <- future_lapply(1:100, FUN = function(i) {
...
value
})
技术细节:
上面设置了一个由“并行”包定义的 PSOCK 集群。这些基本上与 SNOW 集群相同,并且由同一位作者撰写,我认为他也认为 SNOW 集群已被弃用,而不是“并行”提供的内容。换句话说,AFAIK 不再使用 snow/doSNOW 了;parallel/doParallel 取代了这些天。
我会将 MPI 集群放在“高级用法”部分下,即除非您已经设置并运行了一个,或者除非您真的认为您需要 MPI,否则我会保留这些。MPI 还鼓励不同的算法设计以充分利用它们。PSOCK 集群带您走很长一段路,只有您认为您已经用尽了这些,您应该研究 MPI。
Spark是一个完全不同的生物。它是围绕分布式数据(在 RAM 中)的分布式计算而设计的。您的分析可能需要这样做,但是,我再次建议您从上述 PSOCK 集群开始 - 它们会带您走很长一段路。
最后的 PS,如果您有 HPC 调度程序(听起来不像),请使用,说,plan(future.batchtools::batchtools_sge)
而不是。您的代码中没有其他内容需要更改。