Краткое сравнение трёх моделей параллелизма — shared-memory (потоки), message-passing (акторы, MPI) и data-parallel (SIMD/GPU). Для каждой модели — назначение, типичные задачи, ограничения и инструменты.
1) Shared-memory (threads)
- Описание: несколько потоков выполняют код в общем адресном пространстве, синхронизируются через блокировки/атомарные операции/условия.
- Типичные задачи: параллельные алгоритмы с разделяемыми структурами данных (пулы задач, веб‑серверы, GUI, реальное время, параллельные структуры данных).
- Ограничения:
- состояния гонок, дедлоки, тонкая настройка синхронизации;
- масштабируемость ограничена пропускной способностью памяти и конфликтами кэша (NUMA-эффекты);
- сложность корректности при $N$ потоках и при слабой памяти;
- overhead контекстных переключений при большом числе тяжёлых потоков.
- Инструменты/языки: pthreads, C++11/17 std::thread + std::atomic, OpenMP (pragma-параллелизм), Intel TBB, Java threads / java.util.concurrent, C# Tasks, Rust (std::thread, crossbeam), Go (goroutines — лёгкие потоки). Для валидации: ThreadSanitizer, Helgrind.
2) Message-passing (акторы, MPI)
- Описание: процессы/акторы не разделяют память; связываются сообщениями — синхронно или асинхронно. Подходит как для многопроцессорных узлов, так и для распределённых кластеров.
- Типичные задачи: распределённые системы и сервисы, масштабируемые микросервисы, отказоустойчивые приложения (Erlang/Elixir), высокопроизводительные вычисления на кластерах (MPI), конвейерная обработка, графовые и потоковые приложения.
- Ограничения:
- задержки и пропускная способность сети; стоимость сериализации/копирования данных;
- сложность согласованности/гарантий доставки и порядка сообщений;
- при тонкой синхронизации может страдать производительность (latency-dominated);
- потребность в явном дизайне топологии и балансировке нагрузки.
- Инструменты/языки: MPI (MPI_Send/MPI_Recv, MPI collective) для HPC, Erlang/OTP, Elixir, Akka (Scala/Java), Orleans, CAF (C++), ZeroMQ, gRPC, RabbitMQ, actor-фреймворки в Rust (Actix, riker). Для сериализации: Protobuf/FlatBuffers/Cap’n Proto.
3) Data-parallel (SIMD, GPU)
- Описание: одна и та же операция выполняется над большим объёмом данных одновременно (SIMD на CPU, потоковые ядра на GPU). Модель ориентирована на массовый параллелизм с простыми потоками управления.
- Типичные задачи: линейная алгебра, ML (обучение/инференс), обработка изображений/видео, физические симуляции, массовые блочные вычисления.
- Ограничения:
- требуется высокая степень параллелизма и регулярный доступ к памяти (выгодно при больших данных);
- штрафы за разветвления/дивергентный контроль внутри векторных групп (warp), ограниченная локальная память и регистры;
- накладные расходы на копирование CPU↔GPU (PCIe/Память); эффективная работа требует упаковки данных и выравнивания;
- производительность часто ограничена пропускной способностью памяти и occupancy, а не количеством ALU.
- Инструменты/языки: CUDA (NVIDIA), HIP (AMD), OpenCL, SYCL (oneAPI), OpenACC, cuBLAS/cuDNN/Thrust, TensorFlow/PyTorch (автоматически используют GPU), ISPC и векторные интринсики/AVX/NEON для SIMD на CPU. Профилирование: nvprof/nsight, rocprof.
Короткое сравнение и когда выбирать
- Если требуется быстрая синхронизация и общий доступ к структурам на одном узле — shared-memory (threads). Подходит при умеренном $N$ и сложной совместной логике.
- Если система распределена по узлам, нужна отказоустойчивость или сильная изоляция — message-passing (акторы/MPI).
- Если задача — высокопараллельная обработка однотипных данных (матрицы, тензоры) — data-parallel (SIMD/GPU) даёт наибольшую пропускную способность.
- Общая предел производительного ускорения следует Amdahl’у: $S=\frac{1}{(1-p)+\frac{p}{N}}$, где $p$ — параллельная доля, $N$ — число параллельных единиц.
(Выбор модели часто смешанный: например, распределённые узлы с MPI + внутри узла CUDA или многопоточность.)