Одновременная многопоточность (Simultaneous multithreading, SMT) — это функция, позволяющая процессору одновременно обрабатывать команды из двух разных потоков. Но задавались ли вы когда-нибудь вопросом, как это работает? Как процессор отслеживает два потока и распределяет ресурсы между ними?

В статье я объясню, как устроена эта функция. Понимание внутреннего устройства SMT поможет вам решить, подходит ли она для ваших продакшен-серверов. Иногда SMT способна резко повысить производительность системы, но в некоторых случаях она приводит к замедлению. Знание подробностей позволит вам сделать правильный выбор.

Примечание: основная часть изложенного в статье относится к реализации SMT компании Intel, также называемой гипертредингом (hyper-threading). Она основана на научной статье компании, опубликованной в 2002 году.

Предыстория и причины создания гипертрединга


SMT была предложена для оптимизации использования ресурсов процессора. На уровне микроархитектуры процессоры состоят из сотен регистров, множества блоков загрузки/сохранения и арифметических блоков. Чтобы оптимальнее их использовать, процессоры применяют различные техники параллельности на уровне команд (instruction level parallelism, ILP), например, конвейерную обработку команд, суперскалярную архитектуру, исполнение с изменением очерёдности.

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

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

Кроме того, современные процессоры являются суперскалярными, то есть вместо отправки в каждом такте одной команды они могут отправлять несколько. Например, процессоры Intel Core i7 могут отправлять в каждом такте по четыре команды. Этот параметр называется шириной конвейера (issue width) процессора.

Конвейерная обработка команд и суперскалярная архитектура существенно повышают пропускную способность обработки команд и оптимизируют использование ресурсов процессора. Однако на практике такого максимального использования бывает сложно достичь. Чтобы параллельно исполнять такое количество команд, процессору необходимо найти в программе достаточное количество независимых друг от друга команд, что сделать очень трудно.

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

Второй тип — это вертикальные траты, возникающие, когда процессор не может отправить в такте ни одной команды, потому что следующие команды в программе зависят от исполняемых в данный момент.

Горизонтальные и вертикальные траты в процессоре c шириной конвейера в пять команд на такт. Пустые прямоугольники обозначают слоты команд, в которые процессор не может отправить команду

Один из способов оптимизации использования вычислительной мощи заключается в использовании традиционной многопоточности (multithreading), при которой процесс переключает контекст между несколькими потоками. В такой схеме за каждый такт процессор отправляет команды только для одного потока, поэтому при этом всё равно могут возникать пустые горизонтальные траты. Однако в следующем такте процессор может переключить контекст и отправить команды ещё одному потоку, избежав вертикальных трат. Это приводит к более полному использованию CPU, однако при большой ширине конвейеров горизонтальные траты тоже могут быть существенными. Кроме того, существуют дополнительные траты на переключение контекста между потоками.

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

Хотя идея SMT не накладывает ограничений на количество потоков, реализация SMT, созданная компанией Intel (hyper-threading), ограничивает его двумя потоками на ядро.

Реализация одновременной многопоточности на уровне микроархитектуры в процессорах Intel


Мы разобрались в причине появления SMT, а теперь давайте узнаем, как она реализована. Мы опишем подробности реализации, а также поговорим о том, как она работает.

Обычный процессор без SMT может за раз исполнять команды только одного потока, потому что с каждым потоком связан контекст, описывающий текущее состояние программы в процессоре, также называемое состоянием архитектуры. В него включены данные в регистрах, значение счётчика программы, регистров управления и так далее.

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

Двухъядерный процессор без SMT (сверху) и двухъядерный процессор с SMT (внизу). Для реализации SMT в нижнем процессоре состояние архитектуры было дублировано и он выглядит для ОС как четыре ядра.

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

Самые важные подробности работы SMT находятся в её микроархитектурной реализации, так что давайте углубимся в неё.

▍ Микроархитектура процессоров


Архитектура набора команд (instruction set architecture, ISA) — это публичный интерфейс процессора, позволяющий программистам программировать CPU. ISA включает в себя набор команд и регистры, которыми могут пользоваться команды. Микроархитектура процессора — это его внутренние подробности реализации. Разные модели процессоров могут поддерживать одну ISA, но различаться на уровне микроархитектуры.

Микроархитектура состоит из трёх частей: фронтенда, бэкенда и retirement unit. На показанной ниже диаграмме представлена схема микроархитектуры современного процессора:

Схема микроархитектуры современного процессора состоит из фронтенда, бэкенда и retirement unit

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

Бэкенд состоит из ресурсов исполнения, например, из физических регистров, арифметических блоков и блоков загрузки/хранения. Он подхватывает переданные фронтендом декодированные команды, выделяет под них ресурсы исполнения и распределяет их для исполнения. В retirement unit результаты выполненных команд помещаются в состояние архитектуры процессора.

Исполнение команд в процессоре с SMT


Чтобы понять, как работает SMT, мы подробнее поговорим о каждом из трёх компонентов микроархитектуры CPU. Давайте начнём с фронтенда.

▍ Реализация SMT во фронтенде


На рисунке ниже показан фронтенд микроархитектуры в увеличенном виде. Он состоит из множества компонентов, каждый из которых играет собственную роль в получении и декодировании команд. Давайте разберём их один за другим.

Фронтенд процессора X86. Источник: Intel Technology Journal, Vol 06, Issue 01, 2002.

▍ Указатели команд


Чтобы понимать, какие команды нужно получать, фронтенд имеет указатель команд, содержащий адрес следующей команды программы.

В случае процессора с SMT существует два набора указателей команд, независимо друг от друга отслеживающие следующую команду для двух программ.

▍ Трассовый кэш


Указатели команд содержат адреса следующих команд потоков, и фронтенд должен считывать эти команды из указанных адресов. Прежде чем это сделать, он сначала проверяет наличие этих команд в трассовом кэше (trace cache).

Трассовый кэш содержит недавно декодированные трассы команд. Декодирование команд — это затратная операция, а некоторые команды нужно исполнять часто. Наличие этого кэша помогает процессору снизить задержки, связанные с исполнением команд.

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

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

▍ Кэш буфера ассоциативной трансляции команд (Instruction Translation Lookaside Buffer, ITLB)


Если фронтенд не нашёл команду в трассовом кэше (произошёл промах кэша), то он ищет команду по указанному адресу в кэше команд L1. Если произошёл промах и в кэше команд L1, то он вынужден получать команду из кэша следующего уровня или из основной памяти.

Данные кэшей команд L1 используют его виртуальный адрес, но для поиска в основной памяти требуются физические адреса. Чтобы транслировать виртуальные адреса в физические, используется буфер ассоциативной трансляции (ITLB), содержащий недавно транслированные виртуальные адреса.

В процессоре с SMT каждый логический процессор имеет собственный кэш ITLB.

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

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

▍ Очередь микрокоманд


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

Очередь микрокоманд равно разделена между двумя логическими процессорами. Такое статическое разделение позволяет обоим логическим процессорам продвигаться вперёд независимо.

▍ Реализация SMT в бэкенде микроархитектуры


Как только завершается подготовка микрокоманд в uop queue, к своей работе приступает бэкенд. На изображении ниже показан в увеличенном виде бэкенд процессора Intel X86.

Бэкенд процессора Intel X86. Источник: Intel Technology Journal, Vol 06, Issue 01, 2002.

Давайте разберём то, что происходит в компонентах бэкенда.

▍ Распределитель ресурсов для исполнения с изменением очерёдности


Бэкенд берёт микрокоманды из uop queue и исполняет их. Однако он исполняет их не в исходном порядке программы.

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

Движок исполнения с изменением очерёдности состоит из распределителя, определяющего ресурсы, требуемые этим микрокомандам, и распределяющего их в зависимости от их доступности.

Распределитель в одном такте распределяет ресурсы для микрокоманд одного логического процессора, а в следующем такте переключается на другой логический процессор. Если uop queue содержит микрокоманды только для одного из логических процессоров или у одного из логических процессоров исчерпалась его доля ресурсов, то распределитель использует все такты для другого логического процессора.

▍ Общие ресурсы исполнения


Что же это за ресурсы, которые распределитель выделяет для микрокоманд, и как они становятся общими?

Первый ресурс, который требуется микрокомандам — это регистры. На уровне ISA процессор может иметь очень малое количество регистров (например, у X86-64 есть только 16 целочисленных регистров общего назначения), но на уровне микроархитектуры существуют сотни физических целочисленных регистров и схожее количество регистров с плавающей запятой. В процессоре с SMT эти регистры поровну поделены между двумя логическими процессорами.

Наряду с регистрами бэкенд также содержит множество буферов загрузки и хранения. Эти буферы используются для выполнения операций чтения и записи в память. В процессорах с SMT они тоже поровну разделены между логическими процессорами.

▍ Переименование регистров


Чтобы обеспечить возможность исполнения с изменением очерёдности, бэкенду также нужно выполнять переименование регистров. Так как на уровне ISA существует очень ограниченное количество архитектурных регистров, команды программы могут использовать один и тот же регистр для множества независимых команд. А движок исполнения с изменением очерёдности стремится использовать эти команды вне их исходного порядка и параллельно. Для этого он переименовывает исходные логические регистры, используемые в командах программы, в физические регистры. Такое отображение хранится в таблице псевдонимов регистров (register alias table, RAT).

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

▍ Очереди готовности команд


После этапов переименования регистров и распределителя команды почти готовы к исполнению. Они помещаются в два набора очередей — один для команд чтения/записи в память, второй — для всех остальных общих команд. Эти очереди тоже равно разделены между двумя логическими процессорами в ядре с SMT.

▍ Распределители команд


У процессора есть множество параллельно работающих распределителей команд. В каждом такте CPU часть команд из очередей готовности команд передаются распределителям. Очереди в каждом такте переключаются между командами двух логических процессоров, то есть в одном такте они отправляют команду одного логического процессора, а в другом переключаются на второй логический процессор.

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

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

▍ Буфер изменения порядка


Когда исполнение функции завершается и её результат уже готов, он помещается в буфер изменения порядка. Команды исполняются в изменённом порядке, однако передавать их архитектуре процессора нужно в исходном порядке программы. Для этого используется буфер изменения порядка (reorder buffer).

Этот буфер в ядре с SMT поровну разделён между двумя логическими процессорами.

▍ Retirement Unit


Retirement unit (блок вывода) отслеживает, когда команды готовы для передачи состоянию архитектуры процессора, и выводит их в правильном порядке программы.

В ядре процессора с SMT retirement unit попеременно выводит микрокоманды каждого из логических процессоров. Если у одного из логических процессоров нет микрокоманд для вывода, то retirement unit тратит весь канал на другой логический процессор.

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

Подсистема памяти


Мы рассказали, как ресурсы исполнения ядра процессора делятся между логическими процессорами в системе с SMT, но пока не рассматривали доступ к памяти.

▍ Буфер ассоциативной трансляции


Буфер ассоциативной трансляции (translation lookaside buffer, TLB) — это маленький кэш, содержащий трансляцию виртуальных адресов в физические для доступа к данным. TLB по необходимости динамически делится между двумя логическими процессорами. Чтобы различать элементы для двух логических процессоров, каждый элемент также помечается идентификатором логического процессора.

▍ Кэши L1, L2 и L3


У каждого ядра CPU имеется собственный кэш L1. В зависимости от микроархитектуры кэш L2 тоже может быть личным или общим для ядер. Если присутствует кэш L3, то он бывает общим для ядер. Кроме того, кэши не знают о существовании логических процессоров.

Кэши L1 и L2 в двухъядерном процессоре. У каждого ядра есть свои личные кэши L1 и L2.

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

Влияние SMT на производительность


Мы уже рассмотрели практически все аспекты реализации SMT на уровне микроархитектуры и параллельного исполнения команд двух логических процессоров. Теперь давайте поговорим о влиянии на производительность.

▍ Выполнение одного потока на ядре с SMT


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

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

Похоже, если на ядре исполняется только один поток, в процессорах Intel Core не применяется разделение ресурсов. Об этом говорится как об улучшении, добавленном в этом поколении процессоров. Источник: Intel Technology Journal, Vol 14, Issue 3, 2010

Примечание из научной статьи Intel, в которой представлена новая микроархитектура процессоров Intel Core. Говорится, что в этом поколении процессоров отсутствуют лишние затраты, когда на ядре с SMT запущен только один поток.

▍ Выполнение двух потоков на ядре с SMT


Если на двух логических процессорах запущено два потока, то стоит подумать об их паттернах доступа к кэшу. Если потоки агрессивно используют кэш и конкурируют за него, то у них будут возникать конфликты и удаление данных друг друга, что снизит их производительность.

С другой стороны, если потоки по своей природе кооперативны, то они могут помогать повышению производительности друг друга. Например, если один поток создаёт данные, потребляемые другим потоком, то скорость их исполнения повысится благодаря хранению данных в общем кэше.

Если два потока не конкурируют за кэш, то они могут работать нормально, не вредя скорости исполнения друг друга, в то же время оптимизируя использование ресурсов ядра CPU.

Однако многие специалисты считают, что когда программе требуется максимальная производительность, лучше отключать SMT, чтобы один поток имел все доступные ему ресурсы.

▍ Уязвимости, связанные с SMT


Существуют и проблемы безопасности, связанные с SMT, они были обнаружены за несколько последних лет (см. например, здесь и здесь). Из-за общего использования ресурсов и спекулятивного исполнения команд многие из этих проблем создают возможности утечек конфиденциальных данных, чем может пользоваться нападающий. Поэтому в общем случае рекомендуется отключать SMT в системах. Кроме того, ходят слухи, что из-за этих проблем Intel может убрать hyperthreading из своего следующего поколения процессоров (Arrow Lake).

В заключение


Подведём итог. Понимание устройства и работы одновременной многопоточности (SMT) крайне полезно, когда нужно решить, следует ли использовать её в продакшен-серверах. SMT придумана для оптимизации использования ресурсов CPU и повышения скорости обработки команд. Она хорошо справляется с этим, позволяя одновременно выполнять несколько потоков, но у неё существуют и недостатки, о которых следует помнить.

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

Ещё одним важным аспектом является безопасность. Недавно обнаруженные уязвимости показали, что совместное использование ресурсов в CPU с SMT может быть опасным. Оно может привести к раскрытию конфиденциальных данных, поэтому некоторые специалисты рекомендуют отключать SMT в системах, для которых очень важна безопасность.

Так пользоваться ли SMT? Это зависит от многих факторов. Если вашим рабочим нагрузкам требуется максимальная производительность и минимальные задержки, то этого можно достичь отключением SMT. Но если вы работаете с задачами общего назначения, способными выиграть от параллелизма, то стоит попробовать SMT.

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

Ссылки



Telegram-канал со скидками, розыгрышами призов и новостями IT ?

Комментарии (33)


  1. aaoo
    19.08.2024 17:44
    +1

    спасибо за статью. вопрос знатокам: а возможно ли спекулятивное выполнение без SMT? по данным из статьи кажется, что да. и тогда не очень понятно почему хотят избавиться от SMT, ведь по факту уязвимость со спекулятивным выполнением, а не с гипертрединг. или не так понял?


    1. lgorSL
      19.08.2024 17:44

      а возможно ли спекулятивное выполнение без SMT?

      Да


    1. Balling
      19.08.2024 17:44

      SMT недостаточно эффективен. В M2, M3 там четыре потока в каждом ядре — 4 микроинструкции из разных потоков все в один цикл идут.

      А на Intel 2 потока. Это такое...


      1. WASD1
        19.08.2024 17:44
        +1

        Микроинструкции не имеют отношения к потокам исполнения, а только о числу execution-units (в современных процессорах перед каждым из них своя очередь ожидающих инструкций).

        И да не слышал, чтобы Apple (если M2 M3 - это про Apple) использовали SMT (нам cache throttling между ядрами может начаться - в статье об этом неприлично вскользь сказано) - сейчас подход P/E ядра.


      1. VoodooCat
        19.08.2024 17:44

        Это как так он недостаточно эффективен? Он способен и зачастую ведет к улучшению производительности. Меня, как разработчика, интересует компиляция. Компилируем. Включаем SMT и компилируем. Видим как минимум +20% улучшение - и забываем этот бред вообще. Есть задачи где он будет во вред, ну так SMT4 тогда будет еще хуже...


        1. Balling
          19.08.2024 17:44
          +1

          Какие 20%? Каждое логическое ядро это физическое ядро у Intel, если код написан правильно. Имеется в виду, что если 60%, 80%, то уже плохо. Ведь должно быть 95% или 90% по факту дизайна.

          https://superuser.com/a/279803/1033761


          1. dv0ich
            19.08.2024 17:44

            Ведь должно быть 95% или 90%

            Если задача полностью распараллеливается.

            А в компиляции может быть полно однопоточных мест.


            1. Balling
              19.08.2024 17:44
              +1

              распараллеливается

              Операционная система тоже исполняется на этих же логических ядрах.


              1. dv0ich
                19.08.2024 17:44

                Какая связь?


                1. Balling
                  19.08.2024 17:44

                  Т.е. ускорение всё равно есть. Так как нет простоя.


            1. unreal_undead2
              19.08.2024 17:44

              А в компиляции может быть полно однопоточных мест.

              Ну так make -j <сколько надо>. Сами по себе компиляторы обычно однопоточные.


          1. VoodooCat
            19.08.2024 17:44

            Ну, процессор бесконечный цикл вообще может выполнять очень и очень быстро, а че ему? Все в кеше, считать не надо, в память ходить не надо, с внешним миром общаться не надо - сиди и считай тока метрики/такты, только пользы ноль, зато быстро. ))

            Мои 20% это то что я видел на разных процессорах разных поколений, да специфично для задачи, но это все равно вполне себе эффективно. В моем случае каждый 1% транслируется на минуту реального времени. Что бы получить больше и продолжить вертикально масштабироваться - это вообще в другой сегмент железа. Так что очень даже эффективно. Если бы был выбор между 16 SMT ядрами и 20-тью мощными не-SMT ядрами - можно было бы что-то там думать об эффективности, а так оно есть и вполне применимо.


          1. unreal_undead2
            19.08.2024 17:44

            Каждое логическое ядро это физическое ядро у Intel

            Это как раз от HT зависит - его включение не меняет число физических ядер, а логических становится в два раза больше.


          1. Gutt
            19.08.2024 17:44

            Каждое логическое ядро это физическое ядро у Intel,

            Нет, с SMT вы получаете в два раза больше логических ядер, чем есть физических.


            1. Balling
              19.08.2024 17:44

              Нет. Логические ядра и есть физические если всё написано правильно.


              1. unreal_undead2
                19.08.2024 17:44

                Это зависит от процессора и конфигурации в BIOS, а не от кода. Или ваша терминология не совпадает с интеловской )


      1. dv0ich
        19.08.2024 17:44

        У POWER-процев по 8 потоков на ядро может быть.


    1. forever_live
      19.08.2024 17:44

      Если некоторые уязвимости спекулятивного выполнения связаны с гипертредингом, а некоторые -- нет, то можно, убрав гипертрединг, избавиться хотя бы от первых. Логично ведь?

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


    1. WASD1
      19.08.2024 17:44

      Уязвимость со спекулятивным исполнением (к стати нигде даже мельком не видел, чтобы такие атаки реально работали и применялись, в отличии от дыр в ПО).

      SMT - лишь один из способов заэксплуатировать (через общий L1D-Cache) эту уязвимость.

      Как по мне - так проблема в кэшах (о том, что два потока исполнения начинают конкурировать за L1D-Cache процессора вытесняя данные друг-друга написано в конце и очень вскользь).
      Я бы связал это с тем, что сейчас более модный (и возможно более правильный) подход - с P/E ядрами.

      Если вам нужна фоновая работа (как правило не требующая высокой производительности) это планируют на [E]fficient - ядро). Для задач с высокой производительностью вам нужно P[ower] ядро. И за L1D-Cache они между собой не конкурируют.

      П.С.
      Другой вопрос - как в data-центрах продавать процессорное время с SMT-процами.
      Linux же считает сколько задача была спланирована на ядре.
      Сколько реально она выполнялась - зависит от параллельной нагрузки. Клиенты могут быть ОЧЕНЬ сильно недовольны.


    1. Denis1121
      19.08.2024 17:44
      +1

      не очень понятно почему хотят избавиться от SMT

      Если речь о том, что Intel хочет отказаться от гиперпоточности (а точнее новое поколение процессоров у них уже вышло или вот вот скоро выйдет без гиперпоточности, так как анонс был на презентациях). Так это потому что мелкие ядра, да и вообще, более многоядерная архитектура, гораздо эффективнее. Да, гиперпоточность может экономить транзисторный бюджет. Однако, на практике, люди отрубают гиперпотчоность и в некоторых задачах производительность даже растёт (разумеется в теории не должна расти, но отладить код, чтобы всё было идеально очень сложно). А там, где растёт - там энергопотребление непозволительно возрастает, что приводит к перегреву и так переразогнанного процессора, даже под хорошей системой охлаждения, поэтому привет троттлинг и деградация.

      Всё вышесказанное касается именно процессоров "для домашних систем". У северных может быть всё по другому, там, как миниум, площадь поверхности в разы больше (что сильно облегчает охлаждение), и задачи ставятся несколько иного характера.


    1. radiolok
      19.08.2024 17:44
      +2

      Избавиться от НТ могут в том числе и потому что придумали что-то новое, с кодовым названием Rentable Units. Патенту уже год и предполагается что 16+ поколения уже будет такими.


      1. unreal_undead2
        19.08.2024 17:44

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


        1. radiolok
          19.08.2024 17:44

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

          Пока остается только ждать когда все это появится в свежем релизе Intel® 64 and IA-32 Architectures Software Developer Manuals


          1. unreal_undead2
            19.08.2024 17:44

            Не факт что вообще появится - по Megiddo и CSA тоже патенты были, этим всё и закончилось.


  1. WASD1
    19.08.2024 17:44
    +3

    Кажется, что перевод этой статьи - пустая трата сил.
    (Во-вторых: есть сильные подозрения, что в статье - в целях сокрытия деталей от конкурентов - в некоторых важных деталях прямо наврано).

    Главная же проблема - чтобы полезно для себя читать эту статью, требуются сначала предварительные материалы минимум на 2 таких статью (это если прям супер-ускоренно).

    Хотябы самая верхнеуровневая проблематика:
    - что имеем
    - какие проблемы есть
    - какие проблемы хотим решить
    - способ решения.





    1. Denis1121
      19.08.2024 17:44

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


  1. Tzimie
    19.08.2024 17:44

    А что такое декодирование команды и почему это затратная операция? Вот возьмём ассемблер pdp11. Получаем слово, 16 бит. Несколько схем с и или и not и получим выводы принимающие 1 для нужной команды. Обычно надо анализировать не все биты


    1. lgorSL
      19.08.2024 17:44

      У интела переменная длина команд (кажется, от 1 до 15 байт). Чтобы знать, где начинается каждая следующая команда, надо хоть как-то минимально декодировать предыдущую.

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


    1. Balling
      19.08.2024 17:44

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

      https://blog.can.ac/2021/03/22/speculating-x86-64-isa-with-one-weird-trick/

      А вот и все инструкции https://haruspex.can.ac/


  1. vvzvlad
    19.08.2024 17:44

    Блин, вроде интересно, но картинки как будто совершенно не связаны с текстом. Сколько не разглядывал, так и не понял соотношения с написанным.


    1. WASD1
      19.08.2024 17:44

      По сути идея - два фронтэнда (fetch \ decode \ issue) : один бэкэнд.
      Это максимально просто и понятно на уровне идеи.

      А вот чтобы понять дальше - нужно объяснять про современные процессорные архитектурные, что совершенно упущено в статье.

      Бэкэнд, в современных ОоО-процессорах даже близко не похож на то, как на картинке, а представляет собой развитие вот этого подхода:

      https://translated.turbopages.org/proxy_u/en-ru.ru.5f38ea06-66c539fc-e3c02850-74722d776562/https/en.wikipedia.org/wiki/Tomasulo%27s_algorithm

      Если совсем кратко:
      - в кольцевой буфер кладём инструкции
      - регистры разыменовываем с дополнительным уровнем косности (т.е. не AX, а reg-112)
      - когда все регистры инструкции готовы - инструкцию на исполнение
      - когда инструкция исполнилась - оповещаем, что её регистр (переименованный) готов на общую шину
      - фиксируем все исполненные подряд идущие инструкции из хвоста очереди (это называется retire).


  1. iMic
    19.08.2024 17:44

    В самом начале статьи читаем:

    Кроме того, современные процессоры являются суперскалярными, то есть вместо отправки в каждом такте одной команды они могут отправлять несколько. Например, процессоры Intel Core i7 могут отправлять в каждом такте по четыре команды. Этот параметр называется шириной конвейера (issue width) процессора.

    Что, прям любой i7 любого поколения? А любой , i5 нет. Серьёзно? Больше похоже на скрытую рекламу Core i7. Ну или проблема перевода имелся ввиду i7 актуальный момент написания статьи - может тогда он вообще был только один (но какого года статья мы не знаем, а в 2002 вообще не было i7)? Не помешало хотя бы примечание переводчика. А то возникает ощущение жуткой древности и грубых общений - сразу расхотелось читать.


    1. unreal_undead2
      19.08.2024 17:44

      Подозреваю, что на момент написания оригинала любой i7 (начиная с появления этой маркировки) имел ширину 4, так что как пример сойдёт. В новых уже 6.