【发布时间】：2021-08-11 17:01:17
【问题描述】：
我一直在学习使用 parallel 包在 R 中并行化代码，特别是具有 14 个内核的 mclapply() 函数。
我注意到，仅从几次代码运行中，mclapply() 的重复调用（使用相同的参数和相同数量的核心）花费的时间长度明显不同。例如，第一次运行需要 18 秒，下一次运行需要 23 秒，当我背靠背（在相同的输入上）进行时，下一次运行需要 34 秒。所以我等了一分钟，再次运行代码，结果又回到了 18 秒。
在运行代码后是否存在相当于“计算机需要一秒钟才能冷却下来”的情况，这意味着连续运行 mclapply() 的单独调用可能需要越来越长的时间，但要等待分钟左右，然后再次运行mclapply() 使其恢复正常？
我对 R 中的并行化没有太多经验，但这是我能想到的唯一临时解释。知道我的推理是否正确，并更详细地了解为什么会发生这种情况，这将非常有帮助。谢谢！
为了澄清，我的电话是这样的：
RNGkind("L'Ecuyer-CMRG")
set.seed(1)
x <- mclapply(training_data, simulation, testing_data, mc.cores=14, mc.set.seed = TRUE)
连续运行两次对我来说第二次需要更长的时间。等一分钟再运行，又变快了。
【问题讨论】：
-
R 中并行工作的运行时可以基于很多因素，包括数据大小，因为 R 需要在进程之间序列化和传输数据；如果不小，那么这不是微不足道的。此外，您不会说您是否正在重新启动集群，或者集群是否通过您对
mclapply(.)的每次重新应用程序持续存在；如果集群是持久的，并且每个节点中的数据不平凡，那么垃圾收集可能是一个因素。 （否则我假设主机操作系统处于空闲状态。） -
感谢@r2evans 的帮助 - 我的集群通过重新应用程序保持不变。但是，如果垃圾正在收集，那是否意味着我一分钟后的跑步也应该花费更长的时间？当我在函数调用之间让它冷却一分钟时，时间就会恢复正常。
-
垃圾收集不是可预测的事件（除非您手动触发它，这通常是不必要的）。坦率地说，我不知道这是一个问题，但它可能是导致运行时不一致的原因，这就是为什么基准测试工具经常受到虚假“最大值”值的影响（例如，参见
bench的垃圾计数 -收藏：bench.r-lib.org) -
如果您在
mclapply()之前立即触发垃圾收集器（即调用gc()）会有所不同吗？顺便说一句，不，除了垃圾收集，没有“冷却”需求。
标签： r parallel-processing cpu-cores mclapply