Ограничение параллельных потоков равняется количеству процессоров?
Там какие-либо преимущества к ограничению количества параллельных потоков, делающих данную задачу равняться количеству процессоров в хост-системе? Или лучше просто доверять библиотекам, таким как ThreadPool.NET, чтобы сделать правильную вещь..., даже если существует 25 различных параллельных потоков, происходящих в какой-либо данный момент?
4 ответа
Большинство потоков не привязаны к процессору, они заканчивают ожиданием ввода-вывода или других событий. Если вы посмотрите на свою систему сейчас, то я думаю, что у вас есть 100 (если не 1000) потоков, выполняющихся без проблем. По этой мере, вы, вероятно, лучше всего просто оставить пул потоков .NET, чтобы сделать все правильно!
Однако, если все потоки были связаны с процессором (например, что-то вроде трассировки лучей), то было бы неплохо ограничить количество потоков количеством ядер, в противном случае есть шанс, что переключение контекста начнет вредить производительности.
.Пул потоков уже достаточно хорошо справляется с этой задачей. Он пытается ограничить количество выполняемых потоков до количества ядер ЦПУ в вашей машине. Когда один поток заканчивается, он сразу же назначает другой подходящий для выполнения поток.
Каждые 0,5 секунды он оценивает, что происходит с работающими потоками. Когда потоки выполняются слишком долго, он предполагает, что они заглохли, и позволяет другому потоку начать выполнение. Теперь у вас будет запущено больше потоков, чем процессорных ядер. Это может достигать максимального количества разрешенных потоков, установленного функцией ThreadPool.SetMaxThreads().
Начиная с .NET 2.0 SP1, максимальное количество потоков по умолчанию было значительно увеличено до 250 раз по сравнению с количеством ядер. Вы никогда не должны попасть туда. Если бы вы это сделали, вы бы потратили около 2 минут времени, когда, возможно, выполнялось неоптимальное количество потоков. Однако все эти потоки должны были бы быть заблокированы на такое длительное время, а это не совсем типичный шаблон выполнения для потока. С другой стороны, если эти потоки все ждут на одном и том же ресурсе, они, скорее всего, просто по очереди, добавив больше потоков не может улучшить пропускную способность.
Короче говоря, пул потоков будет работать хорошо, если вы запустите потоков, которые выполняются быстро (секунды максимум) и не блокировать в течение длительного времени. Вы, вероятно, должны рассмотреть вопрос о создании собственных объектов Thread, когда ваш код не соответствует этому шаблону.
.Ну, если вашим узким местом являются ТОЛЬКО процессоры, то это может иметь смысл, но это будет игнорировать всю память и другие узкие места i/o, и шансы, по крайней мере, что ваша кэш-память бросает ошибки страниц и другие события, которые будут замедлять потоки.
Я бы сам доверился библиотеке. Потоки ждут всевозможных вещей, и вы не хотите, чтобы ваше приложение замедлилось, потому что оно не может породить новый поток, хотя большинство остальных просто спят, ожидая какого-то события или ресурса.
.Измерьте Ваше приложение при различных соотношениях thread:processor. Делайте выводы, основываясь на достоверных данных о вашем приложении. Не принимайте аргументов из первых принципов о том, какую производительность вы должны получить, важно только то, что вы сделаете .
.