Кратко и по существу — сопоставление по назначению, сильным и слабым сторонам, с примерами задач.
1) Потоки (threading)
- Когда естественна: для CPU-bound задач с общим разделяемым состоянием, где требуется низкая задержка и доступ к общей памяти (например, численные расчёты, многопоточность в системных сервисах, низкоуровневые параллельные алгоритмы).
- Почему: нативный параллелизм на ядрах CPU, прямой доступ к общей памяти даёт эффективный обмен данными без копирования.
- Плюсы: простая модель для параллельных вычислений, детерминированность при корректной синхронизации; хорошая производительность на нескольких ядрах.
- Минусы: дорогостоящие контекстные переключения, сложность синхронизации (гонки, дедлоки), плохо масштабируется на очень большое число задач (потоки обычно эффективны до порядка $10^2$ — $10^3$ на одном узле).
- Примеры: многопоточные CPU-библиотеки, realtime-сервисы с жесткими требованиями к задержке.
2) Событийно-ориентированное программирование (async/await)
- Когда естественна: I/O-bound и высококонкурентные сетевые приложения с большим числом "легких" задач (например, веб-серверы, клиенты, обработка множества соединений, GUI).
- Почему: минимальные расходы на переключение контекста (кооперативная многозадачность), позволяет обслуживать десятки тысяч одновременных операций при малом числе системных потоков.
- Плюсы: высокая масштабируемость по числу задач/соединений, простота кодирования асинхронной логики благодаря синтаксису async/await.
- Минусы: не подходит для тяжёлых CPU-задач (блокирует поток исполнителя), сложнее работать с чисто синхронным API; модель требует неблокирующего стиля.
- Примеры: HTTP-серверы на Node.js/async Python/asyncio, клиенты с большим числом параллельных запросов.
3) Акторная модель
- Когда естественна: системы с распределённым состоянием, высоким уровнем изоляции, требующие масштабируемости и устойчивости (например, телекоммуникации, чат-сервисы, распределённые игры, агентовые системы).
- Почему: акторы инкапсулируют состояние и взаимодействуют только через сообщения — исключается прямой доступ к общему состоянию, что упрощает масштабирование и отказоустойчивость; естественно мапится на распределённые узлы.
- Плюсы: слабая связность, упрощённая модель отказоустойчивости (supervision), удобна для горизонтального масштабирования и распределённых систем.
- Минусы: накладные расходы на сериализацию/передачу сообщений, задержки при асинхронной коммуникации, сложнее гарантий логической согласованности при распределении.
- Примеры: Erlang/OTP, Akka, Orleans для чат-серверов, телеком-матриц, микросервисов со сложным состоянием.
4) GPGPU
- Когда естественна: данные-параллельные задачи с высокой арифметической интенсивностью и малым объёмом ветвления — линейная алгебра, свёртки, физические симуляции, обработка изображений, машинное обучение.
- Почему: GPU содержит сотни/тысячи мелких SIMD-ядер, обеспечивает гигантскую пропускную способность для однотипных операций над большими массивами данных.
- Плюсы: экстремально высокая производительность и эффективность на подходящих задачах (TFLOPS), хорошо масштабируется по размеру данных.
- Минусы: требуется переработка алгоритма в data-parallel стиль, ограничена памятью/коммутацией с CPU (PCIe/CPU-GPU копии), плохо подходит для сильно разветвлённых или зависимых по данным задач.
- Примеры: обучение нейросетей, матричные операции, массовые физические расчёты.
Краткая сводка по выбору:
- Если задача CPU-bound и тесно работает с общей памятью — потоки.
- Если задача I/O-bound с большим числом одновременных соединений — async/await.
- Если нужно много изолированных, взаимодействующих сущностей и/или распределённость/устойчивость — акторы.
- Если задача — масштабная data-parallel числовая работа — GPGPU.
Замечания по сочетанию: в практических системах часто комбинируют модели: например, async-цикл с пулом потоков для CPU-работы или акторы, использующие GPU для тяжёлых вычислений.