Сколько одновременных потоков в приложении много?

Question

5, 100, 1000?

Полагаю, "это зависит", но от чего?

Что общего в приложениях, которые работают как серверные демоны / службы?

Что такое жесткие ограничения?

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

Каковы важные различия между ОС?

Что еще следует учитывать?

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

Я знаю правило n + 1 как руководство для определения количества потоков, которые одновременно работают над одной и той же задачей, чтобы повысить производительность. Тем не менее, я хочу использовать потоки, как можно использовать процессы в большем объеме, т.е. е. организовывать самостоятельные задания, которые не должны мешать друг другу.

В этом связанном вопросе некоторые люди советуют минимизировать количество потоков из-за дополнительной сложности. Мне кажется, что потоки также могут помочь упорядочить вещи и фактически уменьшить помехи. Разве это не правильно?

Answer 1

Я не могу ответить на ваш вопрос о том, «сколько это много», но я согласен, что вы не должны использовать темы для каждой возможной задачи.

Оптимальное количество потоков для производительности приложения равно (n + 1), где n - количество процессоров / ядер вашего компьютера / кластера.

Чем больше ваш фактический объем потока отличается от n + 1, тем менее оптимальным он становится и расходует ресурсы вашей системы на вычисления потоков.

Так, обычно вы используете 1 поток для пользовательского интерфейса, 1 поток для некоторых общих задач и (n + 1) потоки для некоторых задач с большими вычислениями.

Answer 2

Также зависит от вашей архитектуры. Например. в NVIDIA GPGPU lib CUDA вы можете поставить 8-поточный многопроцессорный 512-потоки одновременно. Вы можете спросить, зачем назначать каждому из скалярных процессоров 64 потока? Ответ прост: если вычисление не связано с вычислениями, а связано с вводом-выводом памяти, вы можете скрыть задержки, выполнив другие потоки. Аналогичное относится к обычным процессорам. Я могу помнить, что для параллельной опции make "-j" рекомендуется использовать примерно в 1,5 раза больше ядер, чем вы получили. Многие из задач компиляции являются тяжелым бременем ввода-вывода, и если задача должна ждать жесткого диска, запомните, что ... CPU может работать в другом потоке.

Далее вы должны рассмотреть, насколько дорого стоит переключение задач / потоков. Например. он поставляется бесплатно, в то время как процессор должен выполнить некоторую работу для переключения контекста. Таким образом, в целом вы должны оценить, превышает ли наказание за два переключения задач время, которое блокирует поток (что сильно зависит от ваших приложений).

Answer 3

На самом деле Ajmastrean немного устарел. Цитирую по собственной ссылке

Пул потоков имеет размер по умолчанию 250 рабочих потоков на каждый доступный процессор и 1000 I / O завершения потоки. Количество потоков в пул потоков можно изменить с помощью метод SetMaxThreads.

Но в целом я думаю, что 25 действительно, когда закон убывающей отдачи (и способности программистов следить за происходящим) начинает вступать в силу. Хотя Макс прав, пока все потоки выполняют неблокирующие вычисления, n + 1 - оптимальное число, в реальном мире большинство задач, которые я выполняю, как правило, выполняются с некоторыми операциями ввода-вывода. 1009 *

Answer 4

Microsoft ThreadPool класс ограничивает вас до 25 потоков на процессор. Ограничение основано на переключении контекста между потоками и памяти, используемой каждым потоком. Так что это хорошая рекомендация, если вы работаете на платформе Windows.