r - 是否使用R中的detectCores函数指定并行处理的核心数？

Question

在detectCores()的help中说：


这不适用于直接用于的mc.cores参数
mclapply也不指定makeCluster中的内核数。第一
因为它可能会返回NA，其次是因为它不给
允许的核心数。


但是，我看过很多示例代码，如下所示：

library(parallel)
k <- 1000
m <- lapply(1:7, function(X) matrix(rnorm(k^2), nrow=k))

cl <- makeCluster(detectCores() - 1, type = "FORK")
test <- parLapply(cl, m, solve)
stopCluster(cl)

其中， detectCores()用于指定 makeCluster中的内核数。

我的用例涉及在我自己的多核笔记本电脑（OSX）上运行并行处理，并在各种多核服务器（Linux）上运行并行处理。因此，我不确定是否有更好的方法来指定内核数量，或者对于不打算使用 detectCores的建议是否更适合于要在广泛的硬件和OS环境上运行代码的程序包开发人员。

因此，总而言之：


您是否应该在R中使用 detectCores函数来指定用于并行处理的内核数？
检测到的核心与允许的核心之间的区别是什么，何时才有意义？

Answer 1

我认为使用detectCores作为调用mclapply或makeCluster时的工作程序/进程数量的起点是完全合理的。但是，出于多种原因，您可能希望或需要减少工作人员，甚至在某些情况下您可以合理地增加工作人员。

例如，在某些超线程计算机上，设置mc.cores=detectCores()可能不是一个好主意。或者，如果您的脚本在HPC集群上运行，则不应使用超出作业计划程序分配给作业的资源。在嵌套并行情况下，您还必须小心，例如当您的代码可能被调用函数并行执行时，或者您正在并行执行多线程函数时。通常，在开始长期工作以确定最佳员工数量之前，运行一些初步基准测试是一个好主意。我通常使用top监视基准，以查看进程和线程的数量是否有意义，并验证内存使用是否合理。

您引用的建议特别适合软件包开发人员。对于包开发人员而言，总是在调用detectCores()或mclapply时总是启动makeCluster工作人员是个坏主意，因此最好将决定权交给最终用户。至少该软件包应允许用户指定要启动的工作程序数量，但可以说detectCores()甚至不是一个很好的默认值。这就是为什么mc.cores包中包含detectCores()时getOptions("mc.cores", 2L)的默认值从mclapply更改为parallel的原因。

我认为您引用的警告的真正含义是R函数不应假定它们拥有整个计算机，或者它们是脚本中使用多个内核的唯一函数。如果您在提交给CRAN的程序包中使用mclapply调用mc.cores=detectCores()，我希望您的程序包在被更改之前将被拒绝。但是，如果您是最终用户，并且在自己的计算机上运行并行脚本，则由您决定允许该脚本使用多少个内核。