ipyparallel странное поведение накладных расходов

Question

Im пытается понять, как сделать распределенную обработку с ipyparallel и jupyter ноутбуком, поэтому я сделал некоторый тест и получил нечетные результаты.

from ipyparallel import Client 
%px import numpy as np 

rc = Client() 
dview = rc[:] 
bview = rc.load_balanced_view() 

print(len(dview)) 
print(len(bview)) 

data = [np.random.rand(10000)] * 4 

%time np.sin(data) 

%%time #45.7ms 
results = dview.map(np.sin, data) 
results.get() 

%%time #110ms 
dview.push({'data': data}) 
%px results = np.sin(data) 
results 

%%time #4.9ms 
results = np.sin(data) 
results 

%%time #93ms 
results = bview.map(np.sin, data) 
results.get() 

В чем дело с накладными расходами? Является ли задача i/o связанной в этом случае, и только 1 ядро ​​может сделать это лучше? Я пробовал большие массивы и все еще получал лучшие времена без параллельной обработки.

Спасибо за совет!

Answer 1

Проблема, кажется, io. Push нажимает весь набор данных на каждый узел. Я не уверен в функции карты, но, скорее всего, она разбивает данные на куски, которые отправляются узлам. Таким образом, мелкие куски - более быстрая обработка. Балансировщик нагрузки, скорее всего, отправляет данные и задачу два раза на один и тот же узел, что значительно влияет на производительность.

И как вам удалось отправить данные за 40 мс? Я привык к протоколу http, где только рукопожатие занимает около секунды. Для меня 40 мс в сети молниеносно.

EDIT О больших временах (40мс):

В локальных сетях время пинг 1-10ms считается нормальной ситуацией. Принимая во внимание, что вам сначала нужно сделать рукопожатие (минимум 2 сигнала) и только затем отправить данные (минимум 1 сигнал) и дождаться ответа (другого сигнала), вы уже говорите о 20 мс только для подключения двух компьютеров. Конечно, вы можете попытаться минимизировать время пинга до 1 мс, а затем использовать более быстрый протокол MPI. Но, как я понимаю, это не улучшает ситуацию значительно. Только на порядок быстрее.

Поэтому общие рекомендации - использовать более крупные рабочие места. Например, довольно быстро распределенная инфраструктура (быстрее, чем Celery, основанная на тестах) рекомендует время выполнения задач более 100 мс. В противном случае накладные расходы структуры начинают взвешивать время выполнения, а преимущества параллелизации исчезают. Efficiency on Dask Distributed