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

5, 100, 1000?

Я думаю, «это зависит», но от чего?

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

Каковы жесткие ограничения?

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

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

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

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

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

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

12.12.2008 15:25:36
Возможно, вы могли бы разместить больше информации о вашей операционной среде? Архитектура процессора, размер адресного пространства, операционная система, шаблоны использования приложений, ожидаемая нагрузка - все это имеет значение в мире.
Mihai Limbășan 12.12.2008 15:46:43
Нет, извини, это на самом деле было бы не в моем понимании. Приложение, которое я пишу, предназначено для ряда сред, и я хочу знать, на что мне следует обращать внимание, чтобы я мог лучше оценивать проблемы, связанные с окружающей средой.
Hanno 12.12.2008 16:08:14
4 ОТВЕТА

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

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

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

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

6
12.12.2008 15:33:19
Ну, я знаю правило n + 1 как руководство для определения количества потоков, которые одновременно работают над одной и той же задачей, чтобы повысить производительность. Тем не менее, я хочу использовать потоки, как можно использовать процессы в большем объеме, то есть для организации независимых задач, которые не должны мешать друг другу.
Hanno 12.12.2008 15:37:07
Это зависит от того, какие задачи они представляют. Но в 99% случаев вы можете реализовать это с помощью 1-2 потоков. Например, если вы создаете какой-нибудь игровой сервер, на котором 1k + NPC ходят по улицам, вы обычно проходите через очереди. Таким образом, вы получаете очередь NPC, и когда поток освобождается, он берет 1 NPC из очереди.
bezmax 12.12.2008 15:44:20
Оптимальное количество потоков широко варьируется в зависимости от того, что делает приложение. Если он сильно связан с IO, то оптимальное количество потоков может быть значительно больше, чем количество ядер. Точно так же ваше приложение может иметь несколько потоков в состоянии ожидания / сна.
Greg Beech 12.12.2008 15:56:23
Да, правило n + 1 оптимально для задач Uber-вычисления, где задача зависит только от скорости вычисления, без каких-либо других факторов.
bezmax 12.12.2008 15:59:08
@Max Любая ссылка на правило N + 1? Не могу найти ни одного.
Calvin1602 22.02.2011 13:05:59

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

0
12.12.2008 15:51:22

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

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

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

1
12.12.2008 15:57:55
Я не устарел, Microsoft впереди. Здесь, в Big-Corporation, мы все еще используем .NET 2.0 Framework.
Anthony Mastrean 12.01.2009 21:41:51
На самом деле размер пула потоков был изменен в .NET 2.0. Мы все еще застряли в этих рамках.
Kris Erickson 14.01.2009 17:11:15

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

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

1
12.12.2008 16:44:33