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

Question

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

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

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

Answer 1

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

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

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

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

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

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