Максимальное количество рабочих/подчиненных для параллельной работы снега

Question

Я запускаю петлю foreach со снежным концом на машине для окон. У меня есть 8 ядер для работы. Rscript вызывается через системный вызов, встроенный в скрипт python, поэтому также будет активный экземпляр python.

Есть ли какая-либо польза от того, что у вас нет # workers = # core, а вместо этого #workers < #cores, так что всегда есть открытие для системных процессов или экземпляра python?

Он успешно работает с # рабочими = # ядрами, но могу ли я получить удар производительности, насыщая ядра (максимально возможные потоки) с помощью r экземпляров-исполнителей?

Answer 1

Это будет зависеть от

1. Вашего процессора (в частности, поддержка HyperThreading)
2. Как много информации должно быть скопировано в/из различных изображений
3. Если вы реализуете это в течение нескольких ящиков (LAN)

Для 1) гиперпоточность помогает. Я знаю, что моя машина делает это, поэтому, как правило, у меня в два раза больше рабочих, а мой код завершается примерно в 85% случаев по сравнению с тем, насколько я сопоставлял число рабочих с ядрами. Это не улучшит больше.

2) Если вы не используете forking, например, сокеты, вы работаете так, как будто вы находитесь в парадигме распределенной памяти, что означает создание одной копии в памяти для каждого рабочего. Это может быть нетривиальное количество времени. Кроме того, несколько изображений на одном компьютере могут занимать много места, в зависимости от того, над чем вы работаете. Я часто сопоставляю число работников с номером, потому что удвоение рабочих заставит меня бежать из памяти.

Это усугубляется 3) скоростью сети на нескольких рабочих станциях. Локально между машинами наш коммутатор будет передавать вещи со скоростью около 20 Мбайт/с, что в 10 раз быстрее, чем мои скорости загрузки в Интернете дома, но это темп улитки по сравнению с копиями в том же поле.

Возможно, вы захотите увеличить значение R, чтобы питон имел приоритет, когда ему нужно что-то делать.