В чем же разница между @parallel и pmap?

Как указано в заголовке: в чем же разница между @parallel и pmap? Я не имею в виду очевидный макрос для цикла, а другой работает над функциями, я имею в виду, как точно отличается их реализация и как я должен использовать это знание для выбора между ними?

Причина, по которой я спрашиваю, заключается в том, что многие приложения, которые я пишу, могут использовать либо конструкцию: я мог бы написать цикл и вычислить что-то с помощью @parallel, или обернуть то, что было бы в цикле, в функцию и вызвать pmap на этом. Я слежу за советом по использованию @parallel для вещей, которые быстро оцениваются, и pmap для вызовов, где каждая задача занимает гораздо больше времени (как указано в документации), но я чувствую, что, если у меня есть лучшее понимание что я делаю, я бы мог сделать лучший выбор.

Например: @parallel делить работу перед оценкой? Я заметил, что если я запускаю параллельный цикл, в котором каждый внутренний вызов занимает произвольное количество времени, @parallel может занять много времени, потому что в конце у меня осталось очень мало процессов. pmap на тех же микротестах, похоже, не имеет этого: pmap перераспределение работы по мере необходимости?

Другие вопросы, подобные этому, проистекают из моего незнания того, как именно pmap отличается от @parallel.

ОТВЕТЫ

Ответ 1

@parallel будет выполнять задание и разделить их среди доступных рабочих сразу. Обратите внимание, что в [email protected] мы получим The specified range is partitioned ... across all workers. pmap, и каждый работник начнет работу. Как только работник закончит работу, он предоставит ему следующую доступную работу. Это похоже на многопроцессорную обработку на основе очереди, как это обычно бывает в python. Таким образом, речь идет не столько о "перераспределении" работы, сколько о предоставлении ее в нужное время и в нужном рабочем месте.

Я подготовил следующий пример, который, на мой взгляд, иллюстрирует это. В этом несколько глупом примере у нас есть два рабочих, один из которых медленный, а другой - в два раза быстрее. В идеале мы хотели бы дать быструю рабочую работу в два раза больше работы, чем медленный рабочий. (или, что более реалистично, у нас быстрая и медленная работа, но главное - то же самое). pmap выполнит это, но @parallel не будет.

Для каждого теста я инициализирую следующее:

addprocs(2)

@everywhere begin
    function parallel_func(idx)
        workernum = myid() - 1 
        sleep(workernum)
        println("job $idx")
    end
end

Теперь, для теста @parallel, я запускаю следующее:

@parallel for idx = 1:12
    parallel_func(idx)
end

И верните распечатку:

julia>  From worker 2:  job 1
    From worker 3:  job 7
    From worker 2:  job 2
    From worker 2:  job 3
    From worker 3:  job 8
    From worker 2:  job 4
    From worker 2:  job 5
    From worker 3:  job 9
    From worker 2:  job 6
    From worker 3:  job 10
    From worker 3:  job 11
    From worker 3:  job 12

Это почти сладкое. Рабочие "разделили" работу равномерно. Обратите внимание, что каждый рабочий выполнил 6 заданий, хотя рабочий 2 в два раза быстрее, чем рабочий 3. Он может касаться, но он неэффективен.

Для теста pmap я запускаю следующее:

pmap(parallel_func, 1:12)

и получить результат:

From worker 2:  job 1
From worker 3:  job 2
From worker 2:  job 3
From worker 2:  job 5
From worker 3:  job 4
From worker 2:  job 6
From worker 2:  job 8
From worker 3:  job 7
From worker 2:  job 9
From worker 2:  job 11
From worker 3:  job 10
From worker 2:  job 12

Теперь обратите внимание, что работник 2 выполнил 8 заданий, а работник 3 выполнил 4. Это точно соответствует их скорости и тому, что мы хотим для оптимальной эффективности. pmap - это трудный мастер задачи - от каждого в зависимости от их способности.

Таким образом, рекомендации в документах Julia имеют смысл. Если у вас небольшие простые задания, более вероятно, что эти проблемы с @parallel не вызовут проблем. Однако для больших или более сложных заданий pmap имеет преимущества.