Коротко и по делу — когда `multiprocessing.Pool.map` ускоряет, когда тормозит/падает, и как выбирать модель параллелизма.
Когда даёт ускорение
- CPU‑bound задачи, реализованные в чистом Python (каждая задача много вычисляет): процессы обойдут GIL, поэтому можно получить параллелизм на $p$ ядрах.
- Тяжёлые независимые задачи с большой вычислительной нагрузкой на задачу (высокая «гранулярность»): накладные расходы на создание/коммуникацию амортизируются.
- Когда использован код в C/C++ расширениях, который не освобождает GIL — всё равно процессы дают независимое исполнение.
Когда приводит к замедлению или ошибкам
- Небольшие быстрые задачи: накладные расходы на сериализацию (pickle), передачу данных и запуск/согласование процессов превосходят выигрыш. Формула критерия выгоды: если накладные расходы $O$ и суммарная работа $T$, выгодно, когда
$$O+\frac{T}{p}<T\Rightarrow O<T\left(1-\frac{1}{p}\right).$$ - Сильная передача больших объёмов данных между процессами (большие numpy‑массивы): pickling/copying дорого; может быть медленнее, чем последовательная обработка. Решение — shared_memory или mmap.
- Непересылаемые/несериализуемые объекты: функции-лямбды, локальные/вложенные функции, некоторые объекты (открытые сокеты, итераторы, lock в неправильном состоянии) вызовут ошибки при pickle.
- Платформенные особенности: на Windows/с современных macOS старт процессов через `spawn` требует guard `if __name__ == "__main__":` — без него возможны рекурсивные запуски/ошибки; в Jupyter часто возникают проблемы.
- Конкурентные примитивы и состояние (locks, Manager) могут привести к дедлокам при неправильном использовании.
- Если используются библиотеки, которые сами многопоточные или используют GPU (CUDA): мультипроцесс может усложнить управление контекстами и памятью GPU.
Дополнительные причины замедления
- `Pool.map` собирает все результаты сразу — большое потребление RAM; лучше `imap_unordered` для потоковой обработки.
- Старт процессов (особенно при `spawn`) дорог: короткие одноразовые задачи проигрывают.
Когда альтернативы лучше
- I/O‑bound (сеть, диск, ожидание): лучше потоки (`ThreadPoolExecutor`) или `asyncio` — у них меньше накладных расходов и нет сериализации.
- Большие общие данные, которые нужно шарить: использовать shared memory, `multiprocessing.shared_memory`, `multiprocessing.Array`, или промышленные фреймворки (Dask, Ray).
- Если C‑расширения освобождают GIL (numpy, scipy, numba, numexpr): иногда проще использовать потоки, потому что они разделяют память и меньше сериализации.
Простые правила/критерии выбора модели параллелизма
1. Определи тип задачи:
- I/O‑bound → потоки или async.
- CPU‑bound → процессы (если код держится в Python) или потоки (если расширения освобождают GIL).
2. Оцени гранулярность задач:
- Много мелких задач → избегать процессов или увеличивать chunk size в `map`.
3. Оцени объём данных между задачами:
- Большие массивы → shared memory / mmap / распределённые фреймворки.
4. Оцени требования к общему состоянию:
- Нужна общая изменяемая память → потоки или специальные механизмы для процессов.
5. Платформа и окружение:
- Windows/Jupyter → учти `spawn` и `if __name__ == "__main__":` или используй другие подходы.
6. Накладные расходы vs выигрыш:
- Используй эмпирическое измерение: если ожидаемый выигрыш меньше накладных расходов $O$, параллелизм не нужен.
7. Для прототипа/простоты:
- `concurrent.futures.ProcessPoolExecutor` удобнее и часто предпочтительнее `multiprocessing.Pool`.
Полезные практические советы
- Тестируй с реальными данными и замерами; формальная оценка часто недостаточна.
- Для множества мелких задач задавай параметр `chunksize` у `map` или используй `imap_unordered`.
- Для больших numpy‑объектов посмотри в сторону `multiprocessing.shared_memory` или `joblib` с mmap.
- Внутри Jupyter — используй `multiprocessing.dummy` (потоки) или специальные решения (ipyparallel) если процессы падают.
Короткая формула предсказания ускорения (Amdahl):
$$S(p)=\frac{1}{\alpha +\frac{1-\alpha }{p}},$$ где $\alpha$ — доля строго последовательного кода, $p$ — число процессов.
Если нужно, могу помочь оценить конкретную задачу: опиши тип работы, средний размер входа/выхода и примерное время выполнения одной задачи.