【问题标题】:Calling objective function in parallel when running optimization in R在 R 中运行优化时并行调用目标函数
【发布时间】:2017-02-17 23:12:32
【问题描述】:

我正在 R 中进行优化。我的问题涉及在循环大量数据列表的目标函数上运行 nlm。我想通过并行运行目标函数来加速优化。我该怎么做呢?

在下面的示例中,我设置了一个玩具问题,其中并行解决方案比原始解决方案慢。如何修改代码以减少开销并加快我的nlm 调用的并行化版本?

library(parallel)

## What is the right way to do optimization when the objective function is run in parallel?
## Don't want very_big_list to be copied more than necessary

set.seed(952)

my_objfn <- function(list_element, parameter) {
    return(sum((list_element - parameter) ^ 2))  # Simple example
}

apply_my_objfn_in_parallel <- function(parameter, very_big_list, max_cores=3) {
    cluster <- makeCluster(min(max_cores, detectCores() - 1))
    objfn_values <- parLapply(cluster, very_big_list, my_objfn, parameter=parameter)
    stopCluster(cluster)
    return(Reduce("+", objfn_values))
}

apply_my_objfn <- function(parameter, very_big_list) {
    objfn_values <- lapply(very_big_list, my_objfn, parameter=parameter)
    return(Reduce("+", objfn_values))
}

my_big_list <- replicate(2 * 10^6, sample(seq_len(100), size=5), simplify=FALSE)
parameter_guess <- 20
mean(c(my_big_list, recursive=TRUE))  # Should be close to 50
system.time(test_parallel <- nlm(apply_my_objfn_in_parallel, parameter_guess,
                                 very_big_list=my_big_list, print.level=0))  # 84.2 elapsed
system.time(test_regular <- nlm(apply_my_objfn, parameter_guess,
                                very_big_list=my_big_list, print.level=0))  # 63.6 elapsed

我在笔记本电脑上运行了它(4 个 CPU,所以makeCluster(min(max_cores, detectCores() - 1)) 返回的集群有 3 个内核)。在上面的最后几行中,apply_my_objfn_in_parallelapply_my_objfn 花费的时间更长。我认为这是因为(1)我只有 3 个内核,并且(2)每次nlm 调用并行化目标函数时,它都会建立一个新集群并分解并复制所有my_big_list。这似乎很浪费——如果我以某种方式设置集群并在每次nlm 调用时只复制一次列表,我会得到更好的结果吗?如果是这样,我该怎么做?


在 Erwin 回答后进行编辑(“考虑创建和停止集群一次,而不是在每次评估中”):

## Modify function to use single cluster per nlm call
apply_my_objfn_in_parallel_single_cluster <- function(parameter, very_big_list, my_cluster) {
    objfn_values <- parLapply(my_cluster, very_big_list, my_objfn, parameter=parameter)
    return(Reduce("+", objfn_values))
}

run_nlm_single_cluster <- function(very_big_list, parameter_guess, max_cores=3) {
    cluster <- makeCluster(min(max_cores, detectCores() - 1))
    nlm_result <- nlm(apply_my_objfn_in_parallel_single_cluster, parameter_guess,
                      very_big_list=very_big_list, my_cluster=cluster, print.level=0)
    stopCluster(cluster)
    return(nlm_result)
}

system.time(test_parallel <- nlm(apply_my_objfn_in_parallel, parameter_guess,
                                 very_big_list=my_big_list, print.level=0))  # 49.0 elapsed
system.time(test_regular <- nlm(apply_my_objfn, parameter_guess,
                                very_big_list=my_big_list, print.level=0))  # 36.8 elapsed
system.time(test_single_cluster <- run_nlm_single_cluster(my_big_list,
                                                          parameter_guess))  # 38.4 elapsed

除了我的笔记本电脑(上面以 cmets 表示的经过时间)之外,我还在一台 30 核的服务器上运行了代码。 apply_my_objfn 的经过时间为 107 次,run_nlm_single_cluster 的经过时间为 74 次。令我惊讶的是,时间比我的小笔记本电脑要长,但是当您拥有更多内核时,单集群并行优化击败常规非并行版本是有道理的。


为了完整起见,另一个编辑(请参阅 Erwin 的回答下的 cmets):这是使用分析梯度的非平行解决方案。令人惊讶的是,它比数值梯度慢。

## Add gradients
my_objfn_value_and_gradient <- function(list_element, parameter) {
    return(c(sum((list_element - parameter) ^ 2), -2*sum(list_element - parameter)))
}

apply_my_objfn_with_gradient <- function(parameter, very_big_list) {
    ## Returns objfn value with gradient attribute, see ?nlm
    objfn_values_and_grads <- lapply(very_big_list, my_objfn_value_and_gradient, parameter=parameter)
    objfn_value_and_grad <- Reduce("+", objfn_values_and_grads)
    stopifnot(length(objfn_value_and_grad) == 2)  # First is objfn value, second is gradient
    objfn_value <- objfn_value_and_grad[1]
    attr(objfn_value, "gradient") <- objfn_value_and_grad[2]
    return(objfn_value)
}

system.time(test_regular <- nlm(apply_my_objfn, parameter_guess,
                                very_big_list=my_big_list, print.level=0))  # 37.4 elapsed
system.time(test_regular_grad <- nlm(apply_my_objfn_with_gradient, parameter_guess,
                                     very_big_list=my_big_list, print.level=0,
                                     check.analyticals=FALSE))  # 45.0 elapsed

我很想知道这里发生了什么。也就是说,我的问题仍然是如何使用并行化加速这种优化问题?

【问题讨论】:

标签: r optimization parallel-processing


【解决方案1】:

在我看来,并行函数评估的开销太大,不值得。考虑创建和停止集群一次,而不是在每次评估中。此外,我相信您不提供梯度,因此求解器可能会进行有限差分,这可能导致大量函数评估调用。您可能需要考虑提供渐变。

【讨论】:

  • 谢谢 (+1)。我添加了一个编辑,我按照您的建议在每次 nlm 调用中创建和停止集群一次——它确实加快了速度,但非并行版本仍然更快。我同意你的观点,提供渐变可能会有所帮助,但我对并行版本相对于非并行版本的性能感兴趣。还有其他明显的方法来改进并行化版本吗?即使使用apply_my_objfn_in_parallel_single_cluster,我认为very_big_list 中的数据也被复制得过多。对吗?
  • 我相信parLapply 会随机处理大量数据,如果您只是在并行步骤中廉价地传递数据,那么总开销可能会令人望而却步。克服这个问题的一种方法是使用一些共享内存结构,例如在包 bigmemory 中。
  • labs.hpe.com/research/systems-research/R-workshop/… 的第四张幻灯片看起来很相关。有没有办法 (1) 将my_big_list 分成 N 块(其中 N = 我机器上的核心数),(2) 向每个工人发送一块(一次,然后工人永久引用他们的块数据),以及 (3) 每次nlm 考虑新的参数值时,让工作人员计算其列表中的目标函数值?
猜你喜欢
  • 1970-01-01
  • 2013-09-17
  • 2015-07-23
  • 2016-10-17
  • 1970-01-01
  • 2023-03-18
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多