Для каких задач важнее однопоток?

Question

[Deita]

Зачем всё чаще люди гонятся за "однопотоком", чем многопотоком, где и под какие задачи у CPU важнее однопоток, а где многопоток?

Answer 1

[Василий Банников]

1. Не все задачи можно распараллелить в принципе.
2. Некоторые задачи распараллелить нетривиально
3. Обработка небольших объёмов данных происходит быстрее в однопотоке из-за того что многопоток добавляет по сравнению с ними слишком много накладных расходов.

Answer 2

[Dimonchik]

затем, что многопоток еще надо суметь написать а прогеры неособо заморачиваются

по классике (с) - архивирование однопоточное, например

Comments

[pfg21]

архивирование кстати весьма неплохо параллелится, но нужно логически разработать соответвующий алгоритм.

Answer 3

[mayton2019]

Все современные задачи делятся условно на 2 категории. CPU-bound. IO-bound.

Первые. Это рендеринг графики. Игры. Численные методы. Майнинг. И все такое. Под это делают разбиение задачи на Processes (Windows/Linux), Threads (Posix). Короче бьються на независимые части и запускаются на отдельных процессорах или ядрах или потоках железа. В таком случае загрузка железа максимальна и отдача максимальна. Биг-дата джобы сюда-же можно положить.

И второй тип задачи - это современные бизнес приложения которые большую часть времени (ну допустим 80%)
стоят на паузе и слушают сетевой порт. И как только что-то прилетает они начинают активничать. Практика показала что большую часть таких задач можно запускать в 1 потоке и все будет нормально. Главное чтоб обработчик долго не тупил. Отработал свой реактивный евент. Или там MQ событие или событие актора и перекинулся на следующее.
Вот. Если грамотно делать второй тип то на 10 потоках ОС можно запустить тысячи акторов или веб-хендлеров бизнес приложения и все будет норм. Тоесть мы фокусируемся на том что I/O важнее.

Попытка смешивать эти юзкейсы или менять местами приводила к проблемам. Например если запускать много потоков ОС в рамках одной бизнес задачи то они очень быстро зацепятся за какой-то глобальный объект (mutex, critical section) и большее число времени процессора будет тратиться не на бизнес задачу а обслуживание этой конкуренции. Вобщем конкарренси - это страшная беда. И парадоксально но увеличение числа ядер или процессоров даже не решают проблему конкарренси а усугубляют. Есть доклад по Erlang на эту тему. И вообще самое лучшее конкарренси - это когда его нет.

Есть еще статья Стоунбрейкера (создатель Postgresql) где он рассуждает на тему куда сгорают мегафлопы в современных dbms под нагрузкой и приходит к очень печальным выводам. Почитайте. Это тоже в тему CPU-bound.