2011-01-28 2 views
16

Комментарий к another of my questions говорит, что я могу выполнить только столько «потоков», что я видел в другом месте.Сколько потоков можно запускать одновременно?

Как начинающий новичок, как определить максимальное количество потоков для использования? Или это вопрос длительности вопроса? От чего это зависит? Конфигурация оборудования или что?

(VB в MS Visual Studio с .Net 3.5, если это имеет значение)


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


[Upperdate] Почти семь лет спустя & мы теперь имеем a software recommendations site, поэтому я asked если есть инструмент, чтобы помочь с этим.

+2

Каковы темы? –

+1

+1 хороший вопрос. Каждый из них делает один вызов SOAP для передачи данных сома и ждет его возврата. – Mawg

+1

За исключением, конечно, что «возврат» асинхронный, поэтому они не очень ждут. Другие потоки могут запускаться, как только запрос SOAP (вызов fcuntion) отправляется по HTTP – Mawg

ответ

9

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

Read: Does Windows have a limit of 2000 threads per process?

Кроме того, даже если вы можете запустить 5000 + темы, в зависимости от вашего оборудования, которые могли бы работать намного медленнее, чем в эквивалентной программе 10 потоков. Я думаю, вы должны взглянуть на thread pooling.

+1

+1 Спасибо. Это дает мне возможность взглянуть и начать пытаться понять. Знаете ли вы о каком-либо s/w-инструменте, который может предложить несколько потоков? – Mawg

+2

Я предполагаю, что использование одного потока на ядро ​​процессора является разумным выбором, но это действительно зависит от проблемы, которую вы пытаетесь решить. – Trinidad

+1

+1 С одним на ядро ​​будет сложно смоделировать сотни устройств. – Mawg

2

Это очень зависит от машины. Основными ограничивающими факторами являются CPU и память (хотя в нее могут войти ограничения по ОС).

Что касается .NET, то также вступает в игру конфигурация thread pool.

+0

+1 Спасибо за отзыв – Mawg

8

Как правило, количество потоков, выполняемых одновременно, определяется количеством процессоров и ядер процессора (включая гиперпоточность). То есть, в любой момент времени количество потоков, работающих (в операционной системе), равно количеству «ядер».

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

Откровенно говоря, я бы сказал, что я много делаю многопоточность в .NET/Windows, потому что человек имеет тенденцию делать больше «повреждений», чем пользы, когда у вас нет действительно прочного понимания. У .NET есть концепция пула потоков, и вам нужно знать, как это работает в дополнение к Windows.

В .NET 3.5/4.0 вы должны искать Задачи (Task Parallel Library), так как библиотека намного лучше определяет количество потоков (если вообще) для появления. С TPL threadpool получает капитальный ремонт, и он намного умнее в вопросе о размножении нитей и краже задач и т. Д. Но вы обычно работаете с задачами, а не с потоками.

Это сложная область, и в результате платформа .NET ввела Задачи, чтобы отвлечь программистов от потоков и, следовательно, позволяла времени выполнения быть умным об этом, в то время как программист просто сказал, чего хочет, и не столько о как это сделать.

+1

+1 Да, я боюсь, что могу нанести больше урона, чем пользы. Я также рассмотрю задачи, спасибо – Mawg

+2

Полезно, я нахожу, различать термины «параллелизм» и «параллелизм» (то есть то, что вы называете «по-настоящему одновременным»). – skaffman

+0

+1 хороший момент, спасибо – Mawg

7

Каждый поток потребляет больше памяти (стек ядра, блок среды потока, thread-local, stack ....).AFAIK в Windows нет явного ограничения, поэтому ограничение будет памятью (вероятно, стек для каждого потока).

В нитях Linux больше похож на процессы (с общей памятью), и вы ограничены:

cat /proc/sys/kernel/threads-max 
+0

+ tahnks для информации – Mawg

+0

Удивительный ответ, +1 для подсказки командной строки – ShellFish

0

Я был в состоянии работать 4 потока сразу на моем текущем старом процессоре (2005) Использование CPU EVGA в перед тем, как прозвучит мой зуммер процессора (запрограммировано внутри меню BIOS). Значение i превысило 90 * c. Имейте в виду, что мы говорим о потоках данных, работающих одновременно. хорошим примером может быть одновременное открытие нескольких программ. Но в целом это зависит от того, насколько хорош ваш процессор с многозадачностью. (другими словами, можно обрабатывать многие активные потоки). Безопасным способом тестирования является загрузка «ocscanner (By EVGA)» и «CPU Thermometer» с использованием центрального процессора в OC Scanner. Во время тестирования убедитесь, что ваша температура не превышает 90 * c (или любую температуру, в которой вы чувствуете себя в безопасности) и посмотрите на текущее количество потоков, которые вы запускаете, бросили ваш процессор. начните с 2 потоков, подождите 3-5 минут, наблюдая температуру процессора, добавьте еще один поток, повторите. (НЕ ПРИНИМАЙТЕ СВОЮ УДАЧУ !!!) (НЕ ПРИНИМАЙТЕ, ЕСЛИ ТЕРМОМЕТР ЦП НЕ МОЖЕТ ОБНАРУТЬ ВАШУ ТЕМПЕРАТУРУ !!!)

3

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

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

Тест, который мы выполнили, где я сейчас работаю, с использованием вирусного шаблона для запуска дополнительных задач, показал, что оптимальный уровень близок к счету процессора как кепка. Задачи, запущенные при соотношении «один к одному» с физическим числом ядер, выполнялись примерно на 1 минуту за каждую задачу. Устанавливается в два раза по счетчику процессора, время задачи перешло с 1 минуты в среднем до 5 минут среднего времени для завершения. Он становится геометрически медленнее, чем больше задач, инициированных за счет ядра.

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

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

Чтобы определить это программно, мы используем

var CoreCount = System.Environment.ProcessorCount/2;

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

1

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

+0

Lolx - когда я впервые опубликовал, не было такого понятия, как многоядерный процессор :-) Спасибо за совет +1 – Mawg