У многих процессоров Intel есть поддержка технологии под названием Hyper-threading. Данная технология позволяет выполнять сразу 2 потока команд на одном ядре процессора. Таким образом удается более эффективно использовать вычислительную мощность ядра. Но, технология Hyper-threading используется далеко не во всех процессорах Intel. Технология Hyper-threading присутствует в , а также в некоторых новых Pentium и мобильных Core i5.
У процессоров AMD с архитектурой Zen также есть технология, создающая по два потока вычислений на ядро. И у AMD также не все процессоры получают поддержку данной технологии.
Из-за такого разброса в характеристиках процессоров создается путаница и пользователи часто не могут разобраться, в каких процессорах сколько потоков используется. В данной статье речь пойдет о том, как узнать сколько потоков на вашем процессоре.
Способ № 1. Диспетчер задач.
Самый простой способ узнать сколько потоков , это посмотреть в «Диспетчере задач». Для можно воспользоваться классической комбинацией клавиш CTRL-SHIFT-DELETE. Если у вас операционная система Windows 7 или более новая, то это можно сделать еще и с помощью CTRL-SHIFT-ESC.
После открытия «Диспетчера задач» нужно перейти на вкладку «Быстродействие».
Здесь будет отображаться загруженность процессора и оперативной памяти компьютера. В правой верхней части окна будет отображаться хронология загрузки ЦП. Особенностью данного графика является, то что нагрузка отображается отдельно для каждого из потоков процессора. Поэтому подсчитав количество окошек с графиками можно узнать сколько потоков в процессоре. Например, на скриншоте внизу, отображается 8 графиков с хронологией загрузки процессора, следовательно, на компьютере используется процессор с 8 потоками.
Если у вас Windows 8 или Windows 10, то хронология нагрузки на процессор может отображаться одним графиком. В этом случае вам нужно сначала переключиться на отображение хронологии по логическим процессорам (потокам). Для этого нужно кликнуть правой кнопкой мышки и выбрать «Изменить график – Логические процессоры».
После этого в «Диспетчере задач» появятся отдельные графики для каждого потока вашего процессора. Например, на скриншоте внизу отображается 4 графика, следовательно, в используемом процессоре 4 потока.
Кроме этого, в «Диспетчере задач» Windows 8/10 прямым текстом указывается сколько потоков в процессоре. Сразу под графиками есть блок с информацией. Там в строке «Логические процессоры» указано количество потоков процессора.
Как вы видите, получить информацию о количестве потоков в процессоре можно очень быстро и без использования сторонних программ. Но, если вам нужно больше информации о процессоре, то обойтись инструментами, встроенными в Windows, уже не получится.
Способ № 2. Программы.
Пожалуй, самой известной программой для получения информации о характеристиках процессора является программа CPU-Z. Данная программа является бесплатной, и вы можете . Если вы хотите узнать сколько потоков в процессоре, то вам нужно запустить CPU-Z на своем компьютере и посмотреть значение «Threads», которое находится в правом нижнем углу программы на вкладке «CPU». На скриншоте внизу видно, что у процессора 4 потока.
Кроме CPU-Z можно использовать и другие программы. Например, вы можете прибегнуть . Данная программа отображает массу технической информации о вашем компьютере.
Среди прочего с ее помощью можно узнать и количество потоков процессора. Для этого нужно перейти в раздел «CPU» и посмотреть значение «Threads».
8.2.1. Основные понятия
В операционной системе Windows 2000 поддерживаются традиционные процессы, способные общаться и синхронизироваться друг с другом так же, как это делают процессы в UNIX. Каждый процесс содержит по крайней мере один поток, содержащий, в свою очередь, как минимум одно волокно (облегченный поток). Более того, для управления определенными ресурсами процессы могут объединяться в задания. Все вместе – задания, процессы, потоки и волокна – образует общий набор инструментов для управления ресурсами и реализации параллелизма как на однопроцессорных, так и на многопроцессорных машинах.
Задание в Windows 2000 представляет собой набор, состоящий из одного или нескольких процессов, управляемых как единое целое. В частности, с каждым заданием ассоциированы квоты и лимиты ресурсов, хранящиеся в соответствующем объекте задания. Квоты включают такие пункты, как максимальное количество процессов (не позволяющее процессам задания создавать бесконтрольное количество дочерних процессов), суммарное время центрального процессора, доступное для каждого процесса в отдельности и для всех процессов вместе, а также максимальное количество используемой памяти для процесса и для всего задания. Задания также могут ограничивать свои процессы в вопросах безопасности, например, запрещать им получать права администратора (суперпользователя) даже при наличии правильного пароля.
Как и в системе UNIX, процессы представляют собой контейнеры для ресурсов. У каждого процесса есть 4-гигабайтное адресное пространство, в котором пользователь занимает нижние 2 Гбайт (в версиях Windows 2000 Advanced Server и Datacenter Server этот размер может быть по желанию увеличен до 3 Гбайт), а операционная система занимает остальную его часть. Таким образом, операционная система присутствует в адресном пространстве каждого процесса, хотя она и защищена от изменений с помощью аппаратного блока управления памятью MMU. У процесса есть идентификатор процесса, один или несколько потоков, список дескрипторов (управляемых в режиме ядра) и маркер доступа, хранящий информацию защиты. Процессы создаются с помощью вызова Win32, который принимает на входе имя исполняемого файла, определяющего начальное содержимое адресного пространства, и создает первый поток.
Каждый процесс начинается с одного потока, но новые потоки могут создаваться динамически. Потоки формируют основу планирования центрального процессора, так как операционная система всегда для запуска выбирает поток, а не процесс. Соответственно, у каждого потока есть состояние (готовый, работающий, блокированный и т. д.), тогда как у процессов состояний нет. Потоки могут динамически создаваться вызовом Win32, которому в адресном пространстве процесса задается адрес начала исполнения. У каждого потока есть идентификатор потока, выбираемый из того же пространства, что и идентификаторы процессов, поэтому один и тот же идентификатор никогда не будет использован одновременно для процесса и для потока. Идентификаторы процессов и потоков кратны четырем, поэтому они могут использоваться в роли байтовых индексов в таблицах ядра, как и другие объекты.
Как правило, поток работает в пользовательском режиме, но когда он обращается к системному вызову, то переключается в режим ядра, после чего продолжает выполнять тот же поток, с теми же свойствами и ограничениями, которые были у него в режиме пользователя. У каждого потока есть два стека – один используется в режиме ядра, а другой в режиме пользователя. Помимо состояния, идентификатора и двух стеков, у каждого потока есть контекст (в котором сохраняются его регистры, когда он не работает), приватная область для локальных переменных, а также может быть свой собственный маркер доступа. Если у потока есть свой маркер доступа, то он перекрывает маркер доступа процесса, чтобы клиентские потоки могли передать свои права доступа серверным потокам, выполняющим работу для них. Когда поток завершает свою работу, он может прекратить свое существование. Когда прекращает существование последний активный поток, процесс завершается.
Важно понимать, что потоки представляют собой концепцию планирования, а не концепцию владения ресурсами. Любой поток может получить доступ ко всем объектам его процесса. Все, что ему для этого нужно сделать, – это заполучить дескриптор и обратиться к соответствующему вызову Win32. Для потока нет никаких ограничений доступа к объекту, связанных с тем, что этот объект создан или открыт другим потоком. Система даже не следит за тем, какой объект каким потоком создан. Как только дескриптор объекта помещен в таблицу дескрипторов процесса, любой поток процесса может его использовать.
Помимо нормальных потоков, работающих в процессах пользователя, в операционной системе Windows 2000 есть множество процессов-демонов, не связанных ни с каким пользовательским процессом (они ассоциированы со специальной системой или простаивающими процессами). Некоторые демоны выполняют административные задачи, как, например, запись «грязных» (модифицированных) страниц на диск, тогда как другие формируют пул, и ими могут пользоваться компоненты исполняющей системы или драйверы, которым нужно выполнить какие-либо асинхронные задачи в фоновом режиме. Переключение потоков в операционной системе Windows 2000 занимает довольно много времени, так как для этого необходимо переключение в режим ядра, а затем возврат в режим пользователя. Для предоставления сильно облегченного псевдопараллелизма в Windows 2000 используются волокна, подобные потокам, но планируемые в пространстве пользователя создавшей их программой (или ее системой поддержки исполнения). У каждого потока может быть несколько волокон, так же как у процесса может быть несколько потоков, с той разницей, что когда волокно логически блокируется, оно помещается в очередь блокированных волокон, после чего для работы выбирается другое волокно в контексте того же потока. Операционная система не знает о смене волокон, так как все тот же поток продолжает работу. Так как операционная система ничего не знает о волокнах, то с ними, в отличие от заданий, процессов и потоков, не связаны объекты исполняющей системы. Для управления волокнами нет и настоящих системных вызовов. Однако для этого есть вызовы Win32 API. Они относятся к тем вызовам Win32 API, которые не обращаются к системным вызовам.
Отметим, что операционная система Windows 2000 может работать на симметричных многопроцессорных системах. Это означает, что код операционной системы должен быть полностью реентерабельным, то есть каждая процедура должна быть написана таким образом, чтобы два или более центральных процессора могли поменять свои переменные без особых проблем. Во многих случаях это означает, что программные секции должны быть защищены при помощи спин-блокировки или мьютексов, удерживающих дополнительные центральные процессоры в режиме ожидания, пока первый центральный процессор не выполнит свою работу (при помощи последовательного доступа к критическим областям).
Верхний предел в 32 центральных процессора является жестким пределом, так как во многих местах операционной системы для учета использования центральных процессоров используются битовые массивы размером в 32-разрядное машинное слово. Например, один однословный битовый массив используется для того, чтобы следить, какой из центральных процессоров свободен в данный момент, а другой массив используется в каждом процессе для перечисления центральных процессоров, на которых этому процессу разрешено работать. 64-разрядная версия Windows 2000 должна будет без особых усилий поддерживать до 64 центральных процессоров. Для превышения этого ограничения потребуется существенная переделка программы (с использованием по нескольку слов для битовых массивов).
Во многих процессорах топового уровня есть потоки, как и ядра. Я постараюсь объяснить в чем отличие потока от ядра, и в чем преимущество этих потоков. Потоки появились достаточно давно, а именно еще во времена правления Pentium 4 (до них она был в Ксеонах как суперпоточность).
В то время потоки еще носили сомнительную пользу, некоторые пользователи считали что они только ухудшают производительность.
Но на самом деле, производительность не падала, просто на то время программ, которые могли грамотно работать с двумя потоками — вообще не было. Поэтому, потоки это скорее всего была экспериментальная технология в то время, кстати почти все Pentium D также не имели ее за исключением топовых моделе D955, D965 (это двухядерники с четырьмя потоками).
Теперь немного разберемся с тем, что это вообще такое. Технология потоков называется Hyper-threading и отображается сокращенно: HT (как правило указывается на коробках сбоку). На одно ядро допустим один поток. Если вы задавались иногда вопросом «как увеличить количество потоков процессора», то я вас разочарую — это невозможно, и даже не думайте об этом, это глупости =).
Hyper-threading позволяет хранить состояние сразу двух потоков, поэтому в из под Windows такие потоки выглядят как ядра. То есть, если у вас имеет процессор 2 ядра, то это 4 потока. Соответственно я имею ввиду процессор, который поддерживает гипертрейдинг.
Как работает Hyper-threading? Чтобы вы понимали, то процессор выполняет не только ваши задачи, но и другие, и в том числе служебные. Так вот, обрабатывая данные, поток потом их отправляет, или ждет новых данных из оперативной памяти. В это время, пока он ждет, он может помогать другому потоку. То есть гипертрейдинг призван увеличить производительность процессора, уменьшая время бездействия.
То есть, можно сделать вывод, что количество потоков всегда равно количеству ядер умноженное на два. Никак иначе. Эту технологию разработала Intel, соответственно в AMD-процессорах ее нет, но есть мнение, что у них есть подобная технология, именно поэтому многие считают что в восьми-ядерных процессорах AMD восемь не ядре, а потоков.
В любом случае, эта технология полезна, хоть это и виртуальные ядра — лучше с HT, чем без нее.
Также плюсом является то, что не только система видит такие потоки как настоящие ядра, но и программы, и если программа умеет распараллеливать свою работу, то скорость ее работы будет выше с потоками, чем без.
Теперь вас наверно заинтересует — как узнать количество потоков процессора? Это очень просто. Вам нужно открыть диспетчер задач (по панели задач нажмите правой кнопкой), и перейти на вкладку производительность. Там будет поле ядра, а под ним — количество потоков, вам нужно последнее:
Как видите, число потоков равно числу ядер, потому что мой Pentium G3220 к сожалению не поддерживает технологию HT.
Современные процессоры Intel Core i3, i7 ее поддерживают, а вот i5 — нет (вроде бы только в ноутбуках есть i5 с двумя ядрами и HT, и некоторые процессоры на 1156 сокет, там тоже два ядра и HT). Думаю что маркетинговый ход, чтобы было равно-мерное увеличение производительности моделей серии i.
Если вы думаете, какой процессор лучше — с потоками или нет, то конечно с ними. Иногда (не буду углубляться) цена с поддержкой HT и без невелика, поэтому стоит доплатить и взять тот, что поддерживает HT. Это я так, в общих чертах вам на будущее.
4.1 Процессы
4.1.1 Понятие процесса
Процесс (задача) - программа, находящаяся в режиме выполнения.
С каждым процессом связывается его адресное пространство, из которого он может читать и в которое он может писать данные.
Адресное пространство содержит:
саму программу
данные к программе
стек программы
С каждым процессом связывается набор регистров, например:
счетчика команд (в процессоре) - регистр в котором содержится адрес следующей, стоящей в очереди на выполнение команды. После того как команда выбрана из памяти, счетчик команд корректируется и указатель переходит к следующей команде.
указатель стека
Во многих операционных системах вся информация о каждом процессе, дополнительная к содержимому его собственного адресного пространства, хранится в таблице процессов операционной системы.
Некоторые поля таблицы:
|
Управление процессом |
Управление памятью |
Управление файлами |
|
Регистры Счетчик команд Указатель стека Состояние процесса Приоритет Параметры планирования Идентификатор процесса Родительский процесс Группа процесса Время начала процесса Использованное процессорное время |
Указатель на текстовый сегмент Указатель на сегмент данных Указатель на сегмент стека |
Корневой каталог Рабочий каталог Дескрипторы файла Идентификатор пользователя Идентификатор группы |
4.1.2 Модель процесса
В многозадачной системе реальный процессор переключается с процесса на процесс, но для упрощения модели рассматривается набор процессов, идущих параллельно (псевдопараллельно).
Рассмотрим схему с четырьмя работающими программами.
В каждый момент времени активен только один процесс
С права представлены параллельно работающие процессы, каждый со своим счетчиком команд. Разумеется, на самом деле существует только один физический счетчик команд, в который загружается логический счетчик команд текущего процесса. Когда время, отведенное текущему процессу, заканчивается, физический счетчик команд сохраняется в памяти, в логическом счетчике команд процесса.
4.1.3 Создание процесса
Три основных события, приводящие к созданию процессов (вызов fork или CreateProcess ):
Работающий процесс подает системный вызов на создание процесса
Запрос пользователя на создание процесса
Во всех случаях, активный текущий процесс посылает системный вызов на создание нового процесса.
В UNIX каждому процессу присваивается идентификатор процесса (PID - Process IDentifier)
4.1.4 Завершение процесса
Четыре события, приводящие к остановке процесса (вызов exit или ExitProcess ):
Плановое завершение (окончание выполнения)
Плановый выход по известной ошибке (например, отсутствие файла)
Выход по неисправимой ошибке (ошибка в программе)
Уничтожение другим процессом
Таким образом, приостановленный процесс состоит из собственного адресного пространства, обычно называемого образом памяти (core image ), и компонентов таблицы процессов (в числе компонентов и его регистры).
4.1.5 Иерархия процессов
В UNIX системах заложена жесткая иерархия процессов. Каждый новый процесс созданный системным вызовом fork, является дочерним к предыдущему процессу. Дочернему процессу достаются от родительского переменные, регистры и т.п. После вызова fork, как только родительские данные скопированы, последующие изменения в одном из процессов не влияют на другой, но процессы помнят о том, кто является родительским.
В таком случае в UNIX существует и прародитель всех процессов - процесс init .
Дерево процессов для систем UNIX
4.1.6 Состояние процессов
Три состояния процесса:
Выполнение (занимает процессор)
Готовность (процесс временно приостановлен, чтобы позволить выполняться другому процессу)
Ожидание (процесс не может быть запущен по своим внутренним причинам, например, ожидая операции ввода/вывода)
Возможные переходы между состояниями.
1. Процесс блокируется, ожидая входных данных
2. Планировщик выбирает другой процесс
3. Планировщик выбирает этот процесс
4. Поступили входные данные
Переходы 2 и 3 вызываются планировщиком процессов операционной системы, так что сами процессы даже не знают о этих переходах. С точки зрения самих процессов есть два состояния выполнения и ожидания.
На серверах для ускорения ответа на запрос клиента, часто загружают несколько процессов в режим ожидания, и как только сервер получит запрос, процесс переходит из "ожидания" в "выполнение". Этот переход выполняется намного быстрее, чем запуск нового процесса.
4.2 Потоки (нити, облегченный процесс)
4.2.1 Понятие потока
Каждому процессу соответствует адресное пространство и одиночный поток исполняемых команд. В многопользовательских системах, при каждом обращении к одному и тому же сервису, приходится создавать новый процесс для обслуживания клиента. Это менее выгодно, чем создать квазипараллельный поток внутри этого процесса с одним адресным пространством.
4.2.2 Модель потока
С каждым потоком связывается:
Счетчик выполнения команд
Регистры для текущих переменных
Состояние
Потоки делят между собой элементы своего процесса:
Семафоры
Статистическую информацию.
Адресное пространство
Глобальные переменные
Открытые файлы
В остальном модель идентична модели процессов.
В POSIX и Windows есть поддержка потоков на уровне ядра.
4.2.3 Преимущества использования потоков
Упрощение программы в некоторых случаях, за счет использования общего адресного пространства.
Быстрота создания потока, по сравнению с процессом, примерно в 100 раз.
Повышение производительности самой программы, т.к. есть возможность одновременно выполнять вычисления на процессоре и операцию ввода/вывода. Пример: текстовый редактор с тремя потоками может одновременно взаимодействовать с пользователем, форматировать текст и записывать на диск резервную копию.
4.2.4 Реализация потоков в пространстве пользователя, ядра и смешанное
B - потоки в пространстве ядра
В случае А ядро о потоках ничего не знает. Каждому процессу необходима таблица потоков , аналогичная таблице процессов.
Преимущества случая А :
Такую многопоточность можно реализовать на ядре не поддерживающим многопоточность
Более быстрое переключение, создание и завершение потоков
Процесс может иметь собственный алгоритм планирования.
Недостатки случая А :
Отсутствие прерывания по таймеру внутри одного процесса
При использовании блокирующего (процесс переводится в режим ожидания, например: чтение с клавиатуры, а данные не поступают) системного запроса все остальные потоки блокируются.
Сложность реализации
7 ответов
Это зависит от оборудования, поскольку вы (возможно) не используете теоретический компьютер, а физический аппаратный, поэтому у вас ограниченные ресурсы.
Кроме того, даже если вы можете запустить 5000+ потоков, в зависимости от вашего оборудования, которые могут работать намного медленнее, чем 10-нить-эквивалентная программа. Я думаю, вы должны взглянуть на объединение потоков .
Как правило, количество потоков, которые запускаются одновременно, определяется количеством процессоров и ядер ЦП (включая гиперпоточность), которые у вас есть. То есть, в любой момент времени количество потоков, работающих (в операционной системе), равно числу "ядер".
Сколько потоков, которые вы можете запускать одновременно в вашем приложении, зависит от большого количества факторов. Наилучшим номером (легким человеком) было бы количество ядер на машине, но, конечно же, как будто никто не притворяется (ни одно другое приложение):).
Честно говоря, я бы сказал, что я много занимаюсь многопоточным в.NET/Windows, потому что у человека обычно есть больше "повреждений", чем пользы, когда у вас нет реального понимания..NET имеет концепцию пула потоков, и вам нужно знать, как это работает в дополнение к Windows.
В.NET 3.5/4.0 вы должны смотреть на Задачи (Task Parallel Library), поскольку библиотека намного лучше определяет, как много нитей (если вообще) икру. С TPL threadpool получает капитальный ремонт, и он намного умнее в вопросе о размножении потоков и краже задач и т.д. Но вы обычно работаете с задачами, а не с потоками.
Это сложная область, и в результате платформа.NET ввела Задачи, чтобы отвлечь программистов от потоков и, таким образом, позволить времени выполнения быть умным об этом, в то время как программист просто скажет, что она хочет, и не столько о том, как для этого.
Каждый поток потребляет больше памяти (стек ядра, блок среды потока, thread-local, stack....). AFAIK в Windows нет явного ограничения, поэтому ограничение будет памятью (вероятно, стек для каждого потока).
В потоках Linux больше похожие процессы (с разделяемой памятью), и вы ограничены:
Cat /proc/sys/kernel/threads-max
Довольно хорошее эмпирическое правило при запуске интенсивных задач состоит в том, чтобы запустить тот же номер, что и ваш физический подсчет ядра.
Да, вы можете запускать больше задач, но они будут ждать ресурсов (или потоков в пуле потоков), и ваш ящик, независимо от размера, не может полностью распределить все основные ресурсы процессора в 100% случаев поток из-за фона/других процессов. Таким образом, чем больше задач вы создаете, тем больше потоков вы создаете, поскольку они превосходят фактические возможные параллельные потоки (1 на ядро), тем больше будет выполняться управление ресурсами, очередность и свопинг.
Тест, который мы выполнили, теперь, когда я работаю с использованием вирусного шаблона, чтобы запустить дополнительные задачи, показал, что оптимальный уровень близок к счету процессора как кепку. Задачи, запущенные при соотношении "один к одному" с физическим числом ядер, выполнялись примерно на 1 минуту за каждую задачу. Устанавливается в два раза по счетчику процессора, время задачи перешло с 1 минуты в среднем до 5 минут среднего времени для завершения. Он становится геометрически медленнее, чем больше задач, инициированных за счет ядра.
Так, например, если у вас есть 8 физических ядер, то должны быть самыми быстрыми 8 задач (и использование TPL, по существу 8 одновременных потоков в активном процессе). Существует ваш основной поток или процесс, который создает другие задачи и другие фоновые процессы, но если ящик довольно изолирован для удовольствия от использования ресурсов, они будут довольно минимальными.
Поверхность программирования колпачка вашей задачи основана на подсчете ядра, когда вы жуете задачи из очереди или списка, поэтому при развертывании приложения на коробках разного размера он автоматически настраивается.
Чтобы определить это программно, мы используем
var CoreCount = System.Environment.ProcessorCount / 2;
Зачем делиться на две, спросите вы? Потому что почти все современные процессоры используют логические ядра или гиперпотоки. Вы должны найти со своим собственным тестированием, что, если вы используете логический счет, ваша общая скорость на одну задачу и, следовательно, весь процесс значительно снизится. Физические ядра - это ключ. Мы не могли видеть быстрый способ найти физическое против логического, но быстрый обзор наших ящиков показал, что это последовательно верно. YMMV, но это может стать довольно быстрым.
Мне удалось запустить 4 потока одновременно на моем текущем старом процессоре (2005). Использование EVGA CPU burner до того, как прозвучал мой зуммер процессора. (Запрограммировано в меню BIOS). Значение я превысило 90 * c. Имейте в виду, что мы говорим о потоках данных, работающих одновременно. хорошим примером может быть одновременное открытие нескольких программ. Но в целом это зависит от того, насколько хорош ваш процессор с многозадачностью. (другими словами, можно обрабатывать многие активные потоки). Безопасным способом тестирования является загрузка "ocscanner (By EVGA)" и "CPU Thermometer" с использованием центрального процессора в OC Scanner. Во время тестирования убедитесь, что ваша температура не превышает 90 * c (или любую температуру, в которой вы чувствуете себя в безопасности) и посмотрите на текущее количество потоков, которые вы запускаете, бросили ваш процессор. начните с 2 потоков, подождите 3-5 минут, наблюдая температуру процессора, добавьте еще один поток, повторите. (НЕ ПРИНИМАЙТЕ СВОЮ УДАЧУ!!!) (НЕ ПОПЫТАЙТЕ, ЕСЛИ ТЕРМОМЕТР ЦП НЕ МОЖЕТ СДЕЛАТЬ ВАШУ ТЕМПЕРАТУРУ!!!)
