Приложение видит только половину потоков, доступных на двухпроцессорной машине

Недавно мы приобрели двухпроцессорную рабочую станцию ​​Dell, оснащенную двумя процессорами Xeon 6138 Gold. Каждый ЦП имеет 20 физических ядер (40 логических ядер), то есть всего 40 физических ядер или 80 логических ядер.

И Linux Fedora, и Windows 10 Professional установлены на этом компьютере с использованием двойной загрузки. Обратите внимание, что я сам не устанавливал эту машину.

Диспетчер задач Windows правильно отображает 80 логических ядер. Эти 80 ядер также доступны в Linux, если посмотреть в / proc.

При запуске PBRT (https://www.pbrt.org/) в Linux приложение правильно использует (и насыщает) 80 ядер.

Однако в Windows процесс использует только 40 логических ядер из 80. Я не проверял, но почти уверен, что PBRT использует std :: thread :: hardware_concurrency (), это хороший способ определить количество ядер. Если я заставлю PBRT использовать 80 потоков благодаря параметру командной строки, диспетчер задач Windows не покажет, что все ядра загружены. Только половина из них. Мне кажется, что один процесс Windows не может использовать все 80 логических ядер.

Это ограничение Windows? Это удивительно.

Должен ли я установить определенную версию Windows, чтобы убедиться, что все ядра доступны для одного процесса?

Это 40 логических ядер на одном ЦП или 40 физических ядер на двух ЦП? Можете ли вы как-нибудь использовать все 80, например запустив два экземпляра или используя инструмент тестирования потоков?

that other guy 17.12.2018 21:58

Есть ли в Windows какие-то лицензионные ограничения, которые искусственно ограничивают вас?

Peter Cordes 17.12.2018 23:34

на процессор приходится 40 логических ядер. Да, я могу использовать все 80 логических ядер, если я запускаю два процесса PBRT одновременно. Я вижу это в диспетчере задач.

Martin Frank 18.12.2018 06:37

@PeterCordes, насколько мне известно. Я подтверждаю, что PBRT использует std :: thread :: hardware_concurrency (), как я вижу в коде. Функция, вероятно, возвращает 40 (а не 80) в Windows.

Martin Frank 18.12.2018 13:06

В этом есть смысл. В зависимости от рабочей нагрузки (и объема кэша на поток) выполнение 1 потока на физическое ядро ​​может быть лучше, чем 1 поток на логическое ядро. Но если планировщик ОС выполняет ужасную работу по поддержанию занятости всех физических ядер, тогда это проблема. Кроме того, некоторые рабочие нагрузки действительно выигрывают от запуска нескольких потоков на каждое физическое ядро, чтобы скрыть пропуски переходов, задержку выполнения инструкций и т. д. (даже некоторый код с высокой пропускной способностью, такой как кодирование видео x265, получает небольшое ускорение из-за Hyperthreading на Skylake, примерно на 15% в прошлом, которое я тестировал.)

Peter Cordes 18.12.2018 18:23
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
1
5
102
0

Другие вопросы по теме