Правильно, гиперпоточность работает путем мультиплексирования потоков инструкций каждого потока на этапах внешнего интерфейса и на этапе вывода конвейера из эксплуатации. В модулях RS и MOB мопы из разных потоков могут быть отправлены исполнительным модулям или каналам кэширования в одном и том же цикле. Эти две области конвейера в основном не обращают внимания на гиперпоточность. Также, если один поток остановлен на любом этапе конвейера в конкретном цикле, вся полоса пропускания этого этапа в этом цикле может быть использована другим гиперпотоком (ами). Ресурсы (т.е. записи буфера), выделенные для одного потока из-за разделения, становятся доступными для другого потока (ов), если этот поток переходит в состояние C1 или более глубокого сна, или если гиперпоточность отключена.
Каждый поток имеет собственное архитектурное состояние, как описано в разделе 8.7.1 руководства Intel под названием «Состояние логических процессоров». Большинство архитектурных регистров дублируются для каждого потока. Это достигается путем репликации структуры RAT в конвейере. Память также является частью архитектурного состояния, но все процессоры Intel являются процессорами с общей памятью, что означает, что память распределяется между всеми ядрами системы.
Мне непонятно, во фразе «отключив гиперпоточность, мы могли бы добиться ускорения», какие метрики производительности и справочная система используются для этого сравнения. Если вы хотите сравнить время выполнения настенных часов двух задач в следующих двух конфигурациях:
- Две задачи выполняются на одном физическом ядре с включенной гиперпоточностью и в предположении, что переключение контекста отсутствует.
- Две задачи выполняются на разных физических ядрах с отключенной гиперпоточностью и в предположении, что переключение контекста отсутствует.
Обычно вторая конфигурация дает меньшее время выполнения, но возможные взаимодействия между задачами на ядре с поддержкой HT слишком сложны, чтобы знать наверняка. Например, вы упомянули, что две задачи могут конфликтовать в частных кэшах данных, но также существует возможность обмена данными. Кроме того, то, что происходит в остальной части системы, может повлиять на ускорение, которое вы можете получить при отключении гиперпоточности.
Возможно, вам придется немного отступить и определить, нужно ли это сравнение в первую очередь. Если общее количество задач, которые находятся в рабочем состоянии, не превышает общего количества физических ядер, будет ли ваш гипервизор планировать виртуальные ЦП на разных физических ядрах или упаковать их более плотно на меньшем количестве физических ядер, чтобы разместить другие ядра в спящем состоянии? Например, ядро Liunx обычно предпочитает планировать один поток на каждом физическом ядре перед использованием другого логического ядра каждого ядра. Если количество задач больше, чем количество физических ядер, вам нужно провести другое сравнение, где гипертеги могут дать вам преимущество в избежании переключения контекста. Это основная ситуация, когда гиперпоточность может улучшить общую производительность. Вы даже можете добиться более высокого ускорения, определив, какие пары задач являются хорошими «братьями и сестрами», и изменив их сходство так, чтобы каждая дружественная пара планировалась на одном физическом ядре. Вам придется выполнить эту оптимизацию вручную, потому что большинство операционных систем и гипервизоров не могут сделать это автоматически (но есть предложения по исследованию на этот счет).
Еще одно большое преимущество гиперпоточности заключается в том, что она может обеспечить лучшую производительность на энергию, что является лучшим показателем для использования в случае, если потребление энергии не менее важно для производительности. Например, если есть только две выполняемые задачи, вы можете достичь более высокой производительности в расчете на энергию, если бы две задачи выполнялись на логических ядрах одного физического ядра по сравнению с их запуском на разных физических ядрах, даже если есть изобилие физических ядер.
Общая рекомендация - оставлять гиперпоточность включенной, если у вас нет убедительных эмпирических данных или связанных с безопасностью причин, оправдывающих ее отключение.
person
Hadi Brais
schedule
10.09.2019
