Оптимальная балансировка нагрузки неравных задач и индикаторов выполнения в R - PullRequest
Новая
       32

Оптимальная балансировка нагрузки неравных задач и индикаторов выполнения в R

1 голос
/ 06 ноября 2019

У меня есть N задач, которые я хотел бы распараллелить по M ядрам в R. Эти задачи значительно различаются по тому, как долго они будут выполняться. К счастью, у меня есть приблизительное представление о том, какие задачи будут медленными, а какие - быстрыми. У меня также есть индикатор выполнения, который увеличивается на количество выполненных задач.

Я хочу оптимизировать порядок задач таким образом, чтобы:

  1. Общее время вычислений было сведено к минимуму
  2. Индикатор выполнения отображает оставшееся время, а не оставшиеся задачи.

Для более практического примера: 

do_task <- function(x){
  Sys.sleep(x ** 2)
}

tasks <- 1:10

cl <- parallel::makeCluster(4)
pbapply::pboptions(use_lb = TRUE)
pbapply::pblapply(tasks, do_task, cl = cl)
parallel::stopCluster(cl)
rm(cl)

Общее время обработки составляет 6 минут. и 32 секунды, и индикатор выполнения сначала движется быстро, но затем очень медленно, поскольку задачи занимают все больше и больше времени.

Или от самого длинного к самому короткому: 

tasks <- 10:1

Это занимает 2 минуты и 20 секунд, намного быстрее. Но индикатор выполнения начинается очень медленно, а затем внезапно ускоряется.

Я также пытался чередовать задачи. 

tasks <- c(10,1,9,2,8,3,7,4,6,5)

Это занимает 3 минуты и 20 секунд, не самые быстрые, но даетболее сбалансированный индикатор выполнения.

1 Ответ

0 голосов
/ 13 ноября 2019

Дальнейшие исследования показали, это

Что свидетельствует о плохой балансировке нагрузки в приложении. Они приводят пример, который я адаптировал 

pb <- utils::txtProgressBar(max = 10, style = 3)
progress <- function(n) utils::setTxtProgressBar(pb, n)
opts <- list(progress = progress)
cl <- parallel::makeCluster(4)
doSNOW::registerDoSNOW(cl)
boot <- foreach::foreach(i = tasks, .options.snow = opts)
res_all <- foreach::`%dopar%`(boot, do_task(i))
parallel::stopCluster(cl)

Этот прогон на 105 секунд близок к оптимальному времени в 100 секунд и намного лучше, чем любой другой метод, который я нашел. Индикатор выполнения все еще сильно неравномерен, но, по крайней мере, он быстрый.

...