Кратко — что это, почему масштабирование трудно, и где одна модель выигрывает у другой.
1) Определения (одно предложение каждое)
- Shared-memory: несколько потоков/процессов работают с общей памятью и синхронизируются через блокировки/атомарные операции/фьючерсы (например: pthreads, OpenMP).
- Message-passing: каждый процесс имеет собственную память и общается явно посылкой сообщений (MPI, actor-model, sockets).
2) Трудности масштабирования
Shared-memory
- Координация и синхронизация: блокировки/барьеры приводят к конкуренции за ресурсы и ожиданиям — рост задержек при увеличении числа рабочих.
- Когерентность кэшей: протоколы snooping плохо масштабируются с числом ядер $N$; трафик когерентности и инвалидации может расти как $O(N)$, что создаёт узкое место.
- Память и пропускная способность: общая шина/контроллер памяти и ограниченная пропускная способность DRAM становятся бутылочным горлышком; в NUMA-системах удалённый доступ дороже, требует сложной локализации данных.
- Атомарные операции и барьеры: стоимость синхронных примитивов растёт с $N$, уменьшая эффективность параллелизма (Amdahl): $S(N)=\frac{1}{(1-p)+p/N}$ (где $p$ — параллельная доля).
- Тонкая синхронизация ухудшает масштаб при мелкозернистых задачах (false sharing, frequent locking).
Message-passing
- Коммуникационные задержки и пропускная способность: каждое взаимодействие платит за латентность $L$ и за передачу данных $m$ по полосе $B$: $T_{comm}=L+\frac{m}{B}$. При большом числе участников и частых сообщениях коммуникация доминирует.
- Стоимость коллективных операций: глобальные операции (reduce, all-to-all) имеют сложную сетевую топологию и обычно растут хуже линейно.
- Балансировка нагрузки и раздел данных: плохая разбиение приводит к горлышкам у узлов с большим объёмом сообщений или работы.
- Надёжность и асинхронность: при масштабировании по узлам приходится решать вопросы отказоустойчивости, повторной отправки, упорядочивания сообщений — повышенная сложность.
- Сериализация/копирование данных: при больших сообщениях накладные расходы на маршаллинг/копирование могут быть велики.
3) Где какая модель явно выигрывает
Shared-memory выигрывает когда:
- Низколатентные, тонкозернистые взаимодействия и общие структуры данных внутри одного узла/машины: многопоточные серверы, realtime-приложения, встраиваемые/RTOS, часть in-memory БД внутри одного сервера.
- Программирование проще при общей памяти (быстрое совместное использование сложных структур).
- Пример: параллельная обработка данных внутри многоядерного CPU с частыми мелкими обновлениями общей структуры (локальные кэши, транзакции в памяти).
Message-passing выигрывает когда:
- Горизонтальное масштабирование по множеству машин: кластерные вычисления, суперкомпьютеры (MPI), распределённые сервисы в облаке.
- Требуется отказоустойчивость, изоляция ошибок и независимость адресного пространства (микросервисы, actor-systems, Erlang, Akka).
- Большие данные/параллельные вычисления с явным распределением данных и редким обменом (HPC, MapReduce-подобные задачи, распределённые графовые алгоритмы).
- Пример: масштабируемые численные симуляции на тысячах узлов (MPI), распределённые стриминговые системы и микросервисы.
4) Практические советы и гибриды
- Часто используется гибрид: внутри узла — shared-memory (OpenMP/треды), между узлами — message-passing (MPI). Это сочетает низкую латентность локальных взаимодействий и масштабность сети.
- Выбор зависит от характера взаимодействия: если частые мелкие обмены и общие структуры — shared-memory; если большого объёма распределённая работа и отказоустойчивость — message-passing.
Если нужно, могу кратко сопоставить конкретные API/фреймворки и их применимость.