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