R parLapply занимает больше времени, чтобы закончить - PullRequest
2 голосов
/ 14 мая 2019

Я запускаю функцию parLapply внутри цикла и проверяю странное поведение. Время на итерацию значительно увеличивалось, и такое увеличение не имело особого смысла.

Итак, я начал синхронизировать функции в цикле, чтобы увидеть, какая из них занимает больше всего времени, и я обнаружил, что parLapply занимал> 95% времени. Итак, я вошел в функцию parLapply и синхронизировал ее, чтобы увидеть, совпадают ли промежутки времени внутри и снаружи функции. И они не с большим отрывом. Этот запас увеличивается со временем, и разница может достигать секунд, что сильно влияет на время, необходимое для завершения алгоритма.

while (condition) {
      start.time_1 <- Sys.time()

      predictions <- parLapply(cl, array, function(i){
        start.time_par <- Sys.time()

        #code

        end.time <- Sys.time()
        time.taken_par<- end.time - start.time_par
        print(time.taken_par)

        return(value)
      })

      end.time <- Sys.time()
      time.taken <- end.time - start.time_1
      print(time.taken)
}

Я бы ожидал, что time.taken будет похоже на сумму всех time.taken_par. Но это не так. Сумма всех time.taken_par обычно составляет 0,026 секунды, в то время как time.taken начинается в 4 раза больше этого значения, что хорошо, но затем увеличивается намного (> 5 секунд).

Может кто-нибудь объяснить, что происходит, и / или если то, что я думаю, должно произойти, неправильно? Это проблема с памятью?

Спасибо за помощь!

Edit:

Вывод parLapply следующий. Однако в моих тестах было 10 списков вместо 3, как в этом примере. Размер каждого отдельного списка, который возвращается parLapply, всегда одинаков и в данном случае равен 25.

[1] 11
[[1]]
          1           2           3           4           5           6           7           8           9          10          11          12          13          14 
-0.01878590 -0.03462315 -0.03412670 -0.06016549 -0.02527741 -0.06271799 -0.05429947 -0.02521108 -0.04291305 -0.03145491 -0.08571382 -0.07025075 -0.07704650  0.25301839 
         15          16          17          18          19          20          21          22          23          24          25 
-0.02332236 -0.02521089 -0.01170326  0.41469539 -0.15855689 -0.02548952 -0.02545446 -0.10971302 -0.02521836 -0.09762386  0.02044592 

[[2]]
          1           2           3           4           5           6           7           8           9          10          11          12          13          14 
-0.01878590 -0.03462315 -0.03412670 -0.06016549 -0.02527741 -0.06271799 -0.05429947 -0.02521108 -0.04291305 -0.03145491 -0.08571382 -0.07025075 -0.07704650  0.25301839 
         15          16          17          18          19          20          21          22          23          24          25 
-0.02332236 -0.02521089 -0.01170326  0.41469539 -0.15855689 -0.02548952 -0.02545446 -0.10971302 -0.02521836 -0.09762386  0.02044592 

[[3]]
          1           2           3           4           5           6           7           8           9          10          11          12          13          14 
-0.01878590 -0.03462315 -0.03412670 -0.06016549 -0.02527741 -0.06271799 -0.05429947 -0.02521108 -0.04291305 -0.03145491 -0.08571382 -0.07025075 -0.07704650  0.25301839 
         15          16          17          18          19          20          21          22          23          24          25 
-0.02332236 -0.02521089 -0.01170326  0.41469539 -0.15855689 -0.02548952 -0.02545446 -0.10971302 -0.02521836 -0.09762386  0.02044592 

Edit2:

Хорошо, я выяснил, в чем проблема. У меня есть массив, который я инициализирую, используя vector("list",10000). И в каждой итерации цикла я добавляю список списков в этот массив. Этот список списков имеет размер 6656 байт. Таким образом, за 10000 итераций он даже не добавляет до 0,1 Гб. Однако, когда этот массив начинает заполняться, производительность распараллеливания начинает ухудшаться. Я понятия не имею, почему это происходит, когда я запускаю скрипт на машине с 64 ГБ ОЗУ. Это известная проблема?

...