Сколько процессоров следует использовать с Hyperthreading?

Допустим, у меня есть серверный процессор с 18 ядрами с включенной гиперпоточностью, что означает, что я вижу 36 процессоров в htop.

Чтобы полностью использовать процессор и не влиять на производительность однопоточности, я должен стремиться к тому, чтобы все 36 «ядер» работали на 100%, а ядра HT будут просто выполнять меньше работы и по-прежнему сообщать о 100%, или это будет означать «полные» ядра уже прерываются задачей на его «ядре HT» и, таким образом, выполняют меньше однопоточной работы?

Я знаю, что существует множество переменных, влияющих на производительность HT, я просто хочу знать, что означают показатели процессора при работе с HT.

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

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

Если у вас есть некоторые процессоры, работающие с HT, а другие нет, значит ли это, что вы будете назначать определенные потоки одному типу или другому? Я думаю, что нет: ваши программы будут запускать свои потоки на случайных виртуальных ядрах. Так как же помогает разделение конфигурации? Поскольку каждый ЦП имеет свой собственный кеш, единственное влияние - пропускная способность памяти и нагрузка на когерентность кеша.

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

Там нет простого ответа. Даже с учетом конкретной программы, машина может отличаться от тех людей, которые имеют собственный опыт.

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

Взгляните на 3-й том «Ангер магнум опус» . Если вы внимательно посмотрите на какой-то конкретный процессор, вы можете найти ограничивающие ресурсы среди глубокого конвейера многих шагов, необходимых для выполнения кода. Вам нужно найти случай, когда чрезмерное обязательство заставляет его выполняться медленнее, в отличие от того, чтобы не брать на себя больше работы. В общем, это означало бы какое-то кеширование; и где ресурс распределяется между потоками.

Что означает индикатор ЦП: он сообщает все время, которое не было потрачено на работу в режиме ожидания. Оба логических потока, назначенные ядру, не будут простаивать, даже если фактическая работа, выполненная на одном из них, может быть небольшой. Время, проведенное с конвейером, застряло на несколько циклов, пока результаты не будут готовы, память извлечена, атомарные операции заблокированы и т. Д. Аналогичным образом не следует считать поток отложенным как «не готовый», поэтому он не будет простаивать, и время все еще показывает, как используется. Ожидание в оперативной памяти не будет отображаться в режиме ожидания. Только что-то вроде ввода / вывода блокирует поток и останавливает время зарядки к нему. В общем случае мьютекс операционной системы сделает это, но с появлением многоядерных систем это уже не является надежным, так как «спин-блокировка» не заставит нить вернуться на полку.

Таким образом, показатель процессора 100% не означает, что все идет гладко, если процессор часто застревает в ожидании памяти. Меньшее количество логических ядер, показывающих 90%, вполне может быть выполнено больше, так как оно завершает обработку чисел и теперь ожидает на диске.

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

Измерители ЦП очень плохо говорят о том, насколько большую производительность вы можете выжать из своих многопоточных ЦП. Для этого вы должны запустить свои собственные тесты с различными уровнями физической подписки. Существуют некоторые рабочие нагрузки, которые лучше всего работают с полностью отключенным HT, поэтому включите этот случай в свое тестирование. Это может быть 1: 2 (36 параллельных рабочих), 1: 1,5 или даже 1: 2,5! Это зависит от вашей рабочей нагрузки.

Более подробно, HT реализован на кремнии способами, которые сокращают время, которое процессор проводит в режиме ожидания, когда контекст должен переключаться или сбой предсказания ветвления. Это позволяет достичь 100% использования исполнительного модуля, чем с помощью простых трюков операционной системы. HT развился с момента своего появления, и на современных чипах наблюдается больше параллелизма, чем те, которые мы использовали 10 лет назад.

Существует два профиля выполнения, которые будут влиять на оптимальную точку превышения подписки:

• Большая продолжительность исполнения . Если ваши работники будут работать в течение нескольких минут или часов перед повторной переработкой, например, при выполнении крупных заданий рендеринга или моделирования среды, вы получите более эффективную одноядерную производительность на одного работника. Это снизит ваш коэффициент.
• Короткая продолжительность исполнения . Если ваши рабочие циклы за секунды или небольшие минуты, такие как потоки веб-приложений, накладные расходы, связанные с включением нового процесса, означают, что ваше соотношение будет выше.

Вы должны увидеть, что все 36 ядер работают на 100% - при условии, что программное обеспечение может это сделать (что нетривиально - планирование может быть сложным с таким количеством ядер, поэтому допустимы провалы ниже 100%).

Очевидно, что когда вы «раскалываете» руду с помощью гиперпоточности, значение этих 200% не составляет «2x100%» в выполненной работе. Но это невидимо для любого выполненного измерения (которое происходит из-за загрузки ЦП и не имеет понятия о проделанной работе). Как много работы будет выполнено, зависит от того, что это за работа - где-то больше, чем в 1,5 раза, большую часть времени следует ожидать без гиперпоточности.

Способ реализации гиперпоточности зависит от конкретного процессора Uarch. От Nehalem до Skylake Intel значительно сократила общие части конвейера с фиксированным соотношением (то есть: 50/50), перейдя к динамически разделяемым структурам.

Во всяком случае, в общих чертах, включение HT привело к чуть более медленному однопоточному выполнению, но из-за того, как работает планировщик Linux, это происходит только тогда, когда номер или работающий поток больше, чем количество физических ядер. Как и в таких ситуациях (когда потоки> ядра) вы обычно цените общую пропускную способность максимальной важности, гиперпоточность остается чистым выигрышем.

Как это возможно? Ключевым моментом для понимания является то, что центральный процессор не представляет физические и виртуальные ядра как равные ядра, скорее, он предоставляет последние таким способом, которым планировщик Linux может избежать планирования на них, если доступны любые другие физические ядра. Другими словами, он сначала использует все физические ядра, затем начинает использовать виртуальное.

Это означает, что, как правило, HyperThreading является очень ценной функцией (другие процессоры, такие как Power8, используют еще более глубокие технологии SMT), и что для максимизации пропускной способности вы должны включить его, загружая ЦП как минимум одним потоком на виртуальное или физическое ядро. Для практического примера, чтобы извлечь полную производительность из 18-ядерного процессора, вы должны использовать как минимум 36 потоков.

Существуют два исключения:

1. если все, что вам нужно, это минимизировать задержку из ограниченного набора потоков (где потоки <физические ядра), вы можете отключить HT
2. очень старые процессоры (Pentium4 и, в гораздо меньшей степени, Nehalem) имеют негибкие правила разбиения, которые заставляют процессор разделять многие ключевые ресурсы в соотношении 50/50 независимо от состояния / нагрузки второго потока. В этом случае вам нужно было сравнить свой вариант использования, чтобы убедиться, что добавленная пропускная способность стоит значительно ниже производительности одного потока.