Как я выбираю лучшее количество потоков для hyptherthreading/multicore?

Это хорошо работает в 1.6.0-бета.5:


  {{#link-to "some.route"}}
    Click Me
  {{/link-to}}

Ссылка произойдет, и затем щелчок всплывет до обработчика действий. Это задокументировано (хотя и косвенно) здесь .

Редактировать: исправлен синтаксис при открытии тега ссылки

8
задан Colin Burnett 10 June 2009 в 01:43
поделиться

13 ответов

Вы можете использовать Environment.ProcessorCount , если это единственное, что вам нужно. Но обычно использование ThreadPool действительно является лучшим вариантом.

В пуле потоков .NET также предусмотрены условия для распределения иногда на потоков больше, чем у вас есть ядер, чтобы максимизировать пропускную способность в определенных сценариях, когда многие потоки ждут I / O до конца.

10
ответ дан 3 November 2019 в 12:27
поделиться

Я бы посоветовал вам не пытаться определять это самостоятельно. Используйте ThreadPool и позвольте .NET управлять потоками за вас.

15
ответ дан 3 November 2019 в 12:27
поделиться

Правильное число, очевидно, 42 .

Теперь о серьезном. Просто всегда используйте пул потоков.

1) Если у вас есть длительная задача по обработке (т. Е. С интенсивным использованием ЦП), которую можно разделить на несколько приемов пищи, то вам следует разделить задачу и затем отправить все отдельные рабочие элементы в ThreadPool . Пул потоков будет подбирать рабочие элементы и начинать их перемешивать в динамическом режиме, поскольку он имеет возможности самоконтроля, которые включают запуск новых потоков по мере необходимости и могут быть настроены при развертывании администраторами в соответствии с требованиями места развертывания , в отличие от предварительного вычисления чисел во время разработки. Хотя верно то, что правильный размер разделения вашей задачи обработки может учитывать количество доступных процессоров, правильный ответ во многом зависит от характера задачи и данных, о которых даже не стоит говорить на этом этапе (и, кроме того, в первую очередь должны быть ваши узлы NUMA , расположение памяти и конфликты между блокировками кеша и только после этого количество ядер).

2) Если вы выполняете ввод-вывод (включая вызовы БД) тогда вы должны использовать асинхронный ввод-вывод и выполнять вызовы в ThreadPool, называемые процедурами завершения.

Это единственные веские причины, по которым у вас должно быть несколько потоков, и обе они лучше всего обрабатываются с помощью ThreadPool. Все остальное, в том числе запуск потока по запросу или соединению. на самом деле являются анти-шаблонами в мире Win32 API (fork - допустимый шаблон в * nix, но определенно не в Windows).

Для более специализированного и более подробного обсуждения темы я могу только порекомендовать Rick Статьи Vicik по этой теме:

5
ответ дан 3 November 2019 в 12:27
поделиться

Единственный способ - это комбинация данных и анализа кода на основе данных о производительности.

Различные семейства и скорости ЦП в сравнении со скоростью памяти и другими действиями в системе все сделают настройка отличается.

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

2
ответ дан 3 November 2019 в 12:27
поделиться

Или даже лучше, чем ThreadPool используйте экземпляры задач .NET 4.0 из TPL. Библиотека параллельных задач построена на основе платформы .NET 4.0, которая фактически определяет оптимальное количество потоков для выполнения задач максимально эффективно для вас.

2
ответ дан 3 November 2019 в 12:27
поделиться

Я недавно кое-что читал по этому поводу (см. Принятый ответ на этот вопрос , например).

Простой ответ - вы позволяете операционной системе решать. Он может гораздо лучше решать, что является оптимальным, чем вы.

Есть ряд вопросов по аналогичной теме - поиск «оптимального количества потоков» (без кавычек) дает вам несколько страниц результатов.

1
ответ дан 3 November 2019 в 12:27
поделиться

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

0
ответ дан 3 November 2019 в 12:27
поделиться

В дополнение к подсчету процессоров, вы можете принять во внимание сродство процесса к процессору, подсчитав биты в маске сродства, возвращаемой функцией GetProcessAffinityMask.

0
ответ дан 3 November 2019 в 12:27
поделиться

Оптимальным числом будет просто количество процессоров. Оптимально у вас всегда будет один поток, работающий на ЦП (логическом или физическом), чтобы минимизировать переключение контекста и связанные с ним накладные расходы.

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

Блокировка никогда не бывает оптимальной, но если вы выполняете какую-либо форму блокировки, тогда ответ резко изменится.

Самый простой и легкий способ добиться хорошего (не обязательно оптимального) поведения - использовать пул потоков.

3
ответ дан 3 November 2019 в 12:27
поделиться

Я бы сказал, что это также зависит от того, что вы делаете, если вы создаете серверное приложение, а затем используете все, что вы можете из ЦП через Environment.ProcessorCount или пул потоков - хорошая идея. Но если это работает на настольном компьютере или машине, которая не предназначена для этой задачи, вы можете оставить некоторый процессор в режиме ожидания, чтобы машина «работала» для пользователя.

1
ответ дан 3 November 2019 в 12:27
поделиться

Хорошее практическое правило, учитывая, что вы полностью ограничены процессором, - это processorCount + 1 .

Это +1 потому что вы всегда будете запускать / останавливать / прерывать некоторые задачи, а n задачи почти никогда не будут полностью заполнять n процессоров.

3
ответ дан 3 November 2019 в 12:27
поделиться

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

0
ответ дан 3 November 2019 в 12:27
поделиться

Я написал простое приложение для обработки чисел, в котором использовалось несколько потоков, и обнаружил, что на моей четырехъядерной системе большая часть работы выполнялась за фиксированный период с использованием 6 потоков.

Я думаю, единственный реальный способ определить это испытание или профилирование.

0
ответ дан 3 November 2019 в 12:27
поделиться
Другие вопросы по тегам:

Похожие вопросы: