Как называется гипертрейдинг у амд
Еще раз о Hyper-Threading
Было время, когда понадобилось оценить производительность памяти в контексте технологии Hyper-threading. Мы пришли к выводу, что ее влияние не всегда позитивно. Когда появился квант свободного времени, возникло желание продолжить исследования и рассмотреть происходящие процессы с точностью до машинных тактов и битов, используя программное обеспечение собственной разработки.
Исследуемая платформа
Объект экспериментов – ноутбук ASUS N750JK c процессором Intel Core i7-4700HQ. Тактовая частота 2.4GHz, повышаемая в режиме Intel Turbo Boost до 3.4GHz. Установлено 16 гигабайт оперативной памяти DDR3-1600 (PC3-12800), работающей в двухканальном режиме. Операционная система – Microsoft Windows 8.1 64 бита.
Рис.1 Конфигурация исследуемой платформы.
Процессор исследуемой платформы содержит 4 ядра, что при включении технологии Hyper-Threading обеспечивает аппаратную поддержку 8 потоков или логических процессоров. Эту информацию Firmware платформы передает операционной системе посредством ACPI-таблицы MADT (Multiple APIC Description Table). Поскольку платформа содержит только один контроллер оперативной памяти, таблица SRAT (System Resource Affinity Table), декларирующая приближенность процессорных ядер к контроллерам памяти, отсутствует. Очевидно, исследуемый ноутбук не является NUMA-платформой, но операционная система, в целях унификации, рассматривает его как NUMA-систему с одним доменом, о чем говорит строка NUMA Nodes = 1. Факт, принципиальный для наших экспериментов – кэш память данных первого уровня имеет размер 32 килобайта на каждое из четырех ядер. Два логических процессора, разделяющие одно ядро, используют кэш-память первого и второго уровней совместно.
Исследуемая операция
Исследовать будем зависимость скорости чтения блока данных от его размера. Для этого выберем наиболее производительный метод, а именно чтение 256-битных операндов посредством AVX-инструкции VMOVAPD. На графиках по оси X отложен размер блока, по оси Y – скорость чтения. В окрестности точки X, соответствующей размеру кэш-памяти первого уровня, ожидаем увидеть точку перегиба, поскольку производительность должна упасть после того, как обрабатываемый блок выйдет за пределы кэш-памяти. В нашем тесте, в случае многопоточной обработки, каждый из 16 инициируемых потоков, работает с отдельным диапазоном адресов. Для управления технологией Hyper-Threading в рамках приложения, в каждом из потоков используется API-функция SetThreadAffinityMask, задающая маску, в которой каждому логическому процессору соответствует один бит. Единичное значение бита разрешает использовать заданный процессор заданным потоком, нулевое значение – запрещает. Для 8 логических процессоров исследуемой платформы, маска 11111111b разрешает использовать все процессоры (Hyper-Threading включен), маска 01010101b разрешает использовать по одному логическому процессору в каждом ядре (Hyper-Threading выключен).
На графиках используются следующие сокращения:
MBPS (Megabytes per Second) – скорость чтения блока в мегабайтах в секунду;
CPI (Clocks per Instruction) – количество тактов на инструкцию;
TSC (Time Stamp Counter) – счетчик процессорных тактов.
Примечание.Тактовая частота регистра TSC может не соответствовать тактовой частоте процессора при работе в режиме Turbo Boost. Это необходимо учитывать при интерпретации результатов.
В правой части графиков визуализируется шестнадцатеричный дамп инструкций, составляющих тело цикла целевой операции, выполняемой в каждом из программных потоков, или первые 128 байт этого кода.
Опыт №1. Один поток
Рис.2 Чтение одним потоком
Максимальная скорость 213563 мегабайт в секунду. Точка перегиба имеет место при размере блока около 32 килобайт.
Опыт №2. 16 потоков на 4 процессора, Hyper-Threading выключен
Рис.3 Чтение шестнадцатью потоками. Количество используемых логических процессоров равно четырем
Hyper-Threading выключен. Максимальная скорость 797598 мегабайт в секунду. Точка перегиба имеет место при размере блока около 32 килобайт. Как и ожидалось, по сравнению с чтением одним потоком, скорость выросла приблизительно в 4 раза, по количеству работающих ядер.
Опыт №3. 16 потоков на 8 процессоров, Hyper-Threading включен
Рис.4 Чтение шестнадцатью потоками. Количество используемых логических процессоров равно восьми
Hyper-Threading включен. Максимальная скорость 800722 мегабайт в секунду, в результате включения Hyper-Threading почти не выросла. Большой минус – точка перегиба имеет место при размере блока около 16 килобайт. Включение Hyper-Threading немного увеличило максимальную скорость, но падение скорости теперь наступает при вдвое меньшем размере блока – около 16 килобайт, поэтому существенно упала средняя скорость. Это не удивительно, каждое ядро имеет собственную кэш-память первого уровня, в то время, как логические процессоры одного ядра, используют ее совместно.
Сравнение эффективности Hyper-threading и SMT. Нужен ли i7-9700K?
Неоднократно слышал о более эффективной реализации логических ядер от AMD, в этом сравнении попробуем выяснить так ли это.
реклама
Тестовые стенды
Тестовый ПК AMD
реклама
• МП: ASUS PRIME X470-PRO
• Видеокарта: MSI GeForce GTX 1080 GAMING X plus;
• ОЗУ: G.Skill Trident Z 2×8 GB (F4-3600C15D-16GTZ), 3533 МГц 14-15-14-28-42
реклама
• Охлаждение ЦП: AIO be quiet! Silent Loop 280mm
• SSD: Kingston SSD A400 120GB (Windows 10 Pro со всеми обновлениями, тестовые программы)
• SSD: Samsung SSD 850 EVO 250GB (Игры)
• БП: CoolerMaster V550 550W [RS550-AFBAG1-EU]
реклама
• Корпус: практически открытый стенд
Тестовый ПК Intel
• ЦП: Intel Core i7-8700K, разгон до 5000 МГц, кольцевая шина 4700 МГц
• МП: ASUS PRIME Z370-A
• Видеокарта: ASUS GeForce GTX 1080 Ti STRIX (Биос OC версии)
• ОЗУ: G.Skill Trident Z 2×8 GB (F4-3600C15D-16GTZ), XMP профиль 3600 МГц
• Охлаждение: жидкостное охлаждение ЦП и видеокарты
• SSD: SSD Smartbuy 240GB MLC (Windows 10 Pro со всеми обновлениями, тестовые программы)
• SSD: Samsung SSD 850 EVO 250GB (Игры)
• БП: CoolerMaster V850 850W [RS850-AFBAG1-EU]
• Корпус: Fractal Design Define R5
Разницу в производительности системных ССД вряд ли можно считать сколь-либо значимой.
Методика тестирования
Сравнения процессоров в номинальных режимах работы оставим материалам на других порталах, для этого сравнения использовались разогнанные ЦП. Продукт от Intel для этого пришлось подвергнуть скальпированию, AMD же лишила меня такого интересного времяпрепровождения. В итоге имеем заветные 5 ГГц от Intel при довольно высоком напряжении 1,36. Экземпляр от AMD стабильно работает на 4250 МГц при напряжении 1,3 и совершенно не боится нагрузки linx, требуя только адекватного охлаждения, вариант необслуживаемой системы с радиатором 280 мм, видимо, является минимумом при такой нагрузке.
Для выяснения эффективности реализации логических процессоров от конкурирующих компаний неплохо бы иметь 8 или 12-ядерные процессоры от Intel на массовой платформе и 12 или 16-ядерные от AMD в той же весовой категории, чтобы результаты массовых процессоров со сравниваемыми технологиями столкнуть с этими воображаемыми монстрами с отключением HT/SMT. Пока это невозможно, но уже вот-вот производители грозят насыпать ядер всем и каждому, стремительно загоняя массовую платформу (даже не HEDT) в ценовую категорию бюджетных автомобилей!
Краеугольными считаю режимы 3-3, 3-6 и 6-6 для Intel и, соответственно, 4-4, 4-8, 8-8 для AMD. Они дают представление о приросте производительности при добавлении логических ядер процессору или же добавления аналогичного количества реальных ядер. Свои выводы постараюсь сделать на основе этих режимов, но результаты всех вариантов тестирования предоставлю для упражнений в арифметике всем читателям. Там, где это уместно, добавлю теоретическую производительность одного потока (просто поделю результат на количество потоков) для более солидного вида диаграмм. Оставим без внимания реализацию общения ядер внутри кристалла и немного прикроем глаза на повышение требований к подсистеме памяти при увеличении потоков, да и сложности с повышением влияния фоновых задач при уменьшении количества ядер будем только иметь в виду.
Результаты тестов
Cinebench R15
Любимая игра разгонятелей процессоров после Линкса. Популярный тест даёт представление о способностях ЦП в рендеринге трёхмерного контента.
Используя матан и вычитание, видим прибавку результата у 8700K в режимах 3-6 и 6-6 относительно 3-3 в 209 и 631 балл соответственно, что даёт нам приблизительное значение эффективности логического ядра на уровне 0,33 от эффективности физического ядра. В дальнейшем именно такими вычислениями буду получать этот коэффициент. Для 2700Х аналогичные изыскания в режимах 4-4, 4-8 и 8-8 дают коэффициент 0,45, что ощутимо выше результата процессора синих. Вот и первый намёк на правдивость изначального предположения.
AIDA 5.97.4600
Из обилия тестов этого пакета выберем «CPU Queen» методом выбора первого в списке.
В отличии от Cinebench здесь уже видно уменьшение производительности каждого потока при увеличении их количества, нестрогое следование теории можно оправдать только не совсем идеальной повторяемостью результатов.
Коэффициенты эффективности: HT – 0,47, SMT – 0,75. Эффективность технологий очень высока, но у некоторых компаний выше других. Наглядно этот результат видно отлично у 8700K в режимах 4-8 и 6-6, 2 физических ядра добавляют лишь немногим больше 4 логических в конечный результат по сравнению с режимом 4-4.
7zip 18.05
Популярный архиватор, результат получим в MIPS!
Коэффициенты эффективности: HT – 0,31, SMT – 0,45. Результат очень напоминает полученный в Cinebench R15.
WinRar 5.40
Популярный архиватор, с лецензированием отлитым в мемах, результат получим в КБ/с.
Результаты неоднозначны и вгоняют в ступор. Ясно только, что архиватор этот гораздо эффективнее на системах Intel и не только общим результатом, но и эффективностью логических ядер. Коэффициенты эффективности: HT – 0,6, SMT – 0,32.
Geekbench 4.2.3
Комплексный тест, эмулирующий реальное использование ПК в программных продуктах разной направленности.
Ссылки на расшифровки результатов на сайте программы сохранил и, возможно, попробую сделать более подробное сравнение позже.
Игры
Переходим к играм, и тут есть все основания отказаться от ранее используемой методики, потому как масштабируемости и способности использовать многопоток в количестве больше 8 не завезли практически ни в одну игру. Будем использовать встроенные тесты.
Assassin’s Creed Origins
Современный Ассасин в несовременном Египте должен отвечать за процессорозависимые игры настоящего.
Удивительное рядом, результаты с включенными логическими ядрами выше, большая редкость в играх. Вплоть до 12 потов видно ощутимое повышение производительности от увеличения логических и не только ядер.
Rise of the Tomb Raider
Аналогичная ACO функция, но уже от игры недавнего настоящего.
Вакханалия цвета и неожиданно самые высокие результаты у 8700K в режиме 4-4, у 2700X – 6-6. Чётко видно устоявшуюся тенденцию увеличения производительности при отключении HT/SMT.
World of Tanks enСore
Будет отдуваться за популярные ММО и сетевые игры, малопоточная нагрузка и в тесте случайно.
Результат ожидаем, практически нет разницы сколько ядер у процессора, а вот HT/SMT всё-таки лучше отключить, если вы не стример.
Выводы
Для игр в массе своей, наоборот, ни одна из этих технологий не может считаться эффективной, так как чаще снижает производительность. Предположу, что организация дополнительного потока на силах физического ядра снижает пиковую производительность этого самого одного ядра, а играм чаще всего одно быстрое ядро гораздо важнее их количества (верно для количества ядер больше 3, чудо пни – компромисс). Вдохновляет, что появляются уже игры, способные использовать HT/SMT во благо, и радужные (в хорошем смысле) перспективы преобладают!
Что касается планов Intel, то выход 9700K посеет определённую неопределённость и подарит выбор, но только при условии одинаковой цены с 8700К. Судя по полученным результатам, в большинстве задач 9700K 8-8 будет более производительным, чем 8700К 6-12, особенно в уже вышедших играх и выходящих в ближайшее время. В рабочих же приложениях будет наблюдаться паритет, либо незначительное отставание 8700K. В узком круге задач 8700К будет впереди, но эти задачи не входят в число наиболее часто выполняемых на этом типе процессоров.
1 ядро, 2 потока. SMT, Hyper-threading. Как это работает?
На прошлой неделе я рассказал вам о том, какими могут быть будущие Intel процессоры, а также в общих чертах описал как работают их конвейеры.
К моему удивлению никто не задался вопросом — а где же тут Hyper-threading? Как говориться — покажи, ткни.
Ведь описанные схемы на деле работают в качестве двух логических ядер, а очевидно, что тут ядер — одно.
Однако на самом деле ядра в текущее время для современных процессоров — это уже некоторая условность.
По сути производительность и количество реально параллельно решаемых задач процессором intel зависит от количества портов, о которых я рассказывал в прошлом материале.
В AMD как таковых портов нет, но есть разделение конвейера на два пути для целочисленных и операций с плавающей запятой, где так же есть по несколько исполнительных устройств и именно суммарное количество исполнительных устройств определяет количество параллельно решаемых процессором задач.
А вот как для операционной системе будет показываться одно ядеро — это вопрос того как процессор может коммуницировать со внешним миром.
Но, не всё так просто.
Если бы было всё так просто — intel и AMD уже давно бы так ядра бы и считали, а то у видеокарт ядер тысячи, а у процессоров еле за десятку переваливает.
Есть очень важные различия между процессорами и видеокартами.
Видеокарты решают задачи, которые можно смело и спокойно разделить на миллионы, а то и миллиарды однотипных подзадач? во многом в силу большого количества полигонов и пикселей. Поэтому нет огромной сложности в том, чтобы каждый такт заполнять все блоки исполнительных устройств и производители видеокарт поэтому и называют их ядрами. С центральными процессорами всё куда сложнее. Они постоянно меняют решаемые задачи, именно поэтому широкий набор исполнительных устройств не считается как большое количество ядер. И одни исполнительные устройства не могут заменить другие. То есть одни задачи передаются через одни порты, где есть нужное устройство, а другие задачи — через другие порты.
И того получается, что центральные процессоры, в отличие от процессоров видеокарт — занимают не все свои исполнительные устройства каждый такт. Безусловно — производители процессоров организуют обвязку этих исполнительных устройств так, чтобы каждый такт занимать настолько много исполнительных устройств, насколько это возможно. Для этого организуются очереди выполнения, чтобы выбирать наборы микроопераций, которые могут быть выполнены параллельно в одном такте.
Но в реальности всё равно не всегда получается занять все исполнительные устройства. Если говорить про AMD, так и вовсе задача у процессора может быть сравнительно длительное время только для целочисленных устройств, в таком случае вообще половина процессора простаивает.
И с развитием мощностей процессоров проблема эта становиться более острой, так как про оптимизацию кода уже толком никто не задумывается, вернее на сверхвысокоуровневых языках программирования её сделать нельзя. То что используют программисты — работает через какие-то библиотеки, о функционировании которых программисты не знают.
И вся надежда на то, что компилятор сможет сотворить чудо (чего, естественно, не происходит) и в простых задачах появляются ненужные циклы на миллионы операций, выбираются какие-то не те типы данных под переменные, так сказать, с запасом. И появляются суммарно миллиарды лишних, и что ещё печальнее, полностью однотипных операций для процессора.
Что это будет значить для центрального процессора?
Для него это будет значить, что он раз за разом, такт за тактом будет использовать только один из всех исполнительных устройств, а все другие будут практически постоянно стоять в простое. В таком случае — теоретическая и практическая производительность будут отличаться в разы, естественно не в пользу практической.
Чтобы было нагляднее — представим эту ситуацию на схеме. Тут по вертикали у меня расположены порты к исполнительным устройствам, а по горизонтали — такты работы процессора.
Плохая для процессора задача каждый такт занимает только один порт, и ещё периодически требуется задействование портов, используемых для данных. Можно увидеть, что почти весь процессор находиться в простое. Не задействован его потенциал и на 20%. И не надо путать это с процентом загрузки процессора. Показанная ситуация в программах мониторинга процессора будет показывать 100% загрузку процессора
Проблема эта вполне реальная и, естественно, производители процессоров с ней борются.
И самый очевидный метод — разрешить операционной системе выполнять вместе несколько программ. Вакантных для работы портов, очевидно настолько много, что особых проблем с тем чтобы выполнять ещё что-то нет.
Допустим мы разрешили операционной системе распознавать ядро не как одно, а как два. В таком случае — операционная система на одно ядро подмешивает два выполняемых процесса. Естественно оба эти процесса декодируются в микрооперации и помещаются в общую очередь переупорядочивания и выполнения микроопераций. И из этой очереди с большим шансом процессор сможет выбрать задачи так, чтобы заполнять ещё какие-то порты в каждом такте, которые бы в противном случае пустовали бы.
Естественно работает это не 100% идеально. То есть если задача более менее нормальная, то она, благодаря построению очередей, может занимать по несколько портов каждый такт.
Другая задача тоже будет занимать по несколько портов каждый такт.
Если просто тупо совместить эти два потока — то часто выходило бы и то, что задачи по портам пересекались бы.
Естественно так как задачи расположены будут в одной очереди, то процессор не допустит конфликтов, но в тоже время — из-за этого выполнение двух задач на одном ядре будет всё равно немного медленнее, чем выполнения задач каждой на своём ядре.
Но и надо понимать, что процессоры проектируют тоже не дураки, и подбирают наборы исполнительных устройств за каждым из портов не случайным образом.
Допустим, зачастую для обычных задач нужен ALU, а не какие-то более редкие устройства. Поэтому если обоим программам нужен будет в основном ALU, то у текущих процессоров intel ALU есть во всех 4-х портах с вычислительными исполнительными устройствами, и в таком случае конфликтов не будет и процессор просто будет разводить задачи на разные ALU и при таких задачах, скорее всего отличия от удвоения производительности будет связано с ограничением при работе с данными.
Из рассказа может показаться, что это запихивание двух потоков в одно ядро штука чисто программная.
Во многом оно, конечно, так и есть. Но и для аппаратной начинки — место тоже нашлось.
В общем-то если бы это была чисто софтверная фишка, то скорее всего производители процессоров и операционных систем уже смогли бы реализовать динамическую мультипоточность. То есть отслеживать степень занятости исполнительных устройств процессора, и добавлять виртуальные потоки на каждое ядро пока ядро не будет забиваться задачами до отказа.
На деле всё сложнее и есть и недостатки такого подхода.
Первая проблема — изолированное выполнение разных потоков.
Несмотря на общие очереди процессор не должен разрешать использовать данные одного потока для работы другого. И это, кстати, одно из мест в которых возникают аппаратные уязвимости процессоров.
То есть стороннее приложение может попытаться в обход защиты получить данные предназначенные для другого приложения. Естественно если попытаться реализовать динамическую систему мультипоточности, то скорее всего, останутся в кешах и регистрах какие-то подвешенные данные до их замещения новыми после закрытия потока для ядра. И этим смогут пользоваться приложения вирусы.
Ещё одна проблема — это общие данные для потоков. Не обязательно, что на нескольких потоках раскиданы два разных приложения. Одно приложение тоже может быть распараллелено. Если создавать и завершать потоки, то образуется сумятица по внутренним адресам данных, то есть надо будет тратить много времени на завершение процессов, запись результатов под новыми внешними для процессора адресами, потом остальные потоки нужно будет заново обеспечить перекрёстными данными. В общем — суматоха та ещё. Собственно эта суматоха и приводит к появлению уязвимостей.
Ещё одна проблема — обработка прерываний от изначально неизвестного количества потоков. Если количество потоков на ядро будет меняться, то процессор должен быть всё равно адаптирован под максимально возможное количество потоков, чтобы обеспечить возможность штатно отрабатывать прерывания.
То есть на каждый из потоков в ядре может одновременно прийти какое-то действие вызывающее прерывание и приоритетное выполнение. Неопределённое количество потоков создаёт проблемы, опять же, в том числе, и с изменением перекрёстных данных для разных потоков в одном ядре.
В общем мультипоточность — это, к сожалению, не чисто софтверная штука, а имеет и аппаратные ограничения и просто так менять на лету число потоков на ядро тоже нельзя.
Но даже учитывая строгое задание числа потоков на ядро есть недостатки и у такого решения.
В intel есть разделение регистров на потоки на входе в процессор инструкций. Физически этого деления нет, но для каждого потока выделяется строго половина из доступного объёма регистровой памяти. Это, скорее всего, нужно как раз для дальнейшей защиты данных одного потока от другого, то есть возможно первоначальные адреса в регистрах сами по себе указывают на то, для какой операции надо разрешать доступ к тем или иным данным.
Естественно и удельного объёма кеш памяти тоже на один поток становиться меньше. То есть для эффективной работы нужно больше кеша на ядро.
Ну, и, конечно, есть проблемы и софтверные.
Я, как человек купивший себе в 2003 году 4-ый пентиум с одним ядром и двумя потоками, могу вас заверить, что оптимизация под многопоток и под гипертрединг однозначно нужна. Без этой оптимизации процессор становиться медленнее для каждой задачи, даже если второй поток ядра простаивает.
И тогда, в 2003 году отключение HT было довольно действенной мерой по повышению производительности.
Сейчас отчасти это тоже работает в некоторых задачах на процессорах с очень большим числом ядер по тем же причинам, то есть не оптимизированный софт под нужное количество потоков и сложности организации работы связки — процессор, операционная система и выполняемая программа при работе с настоящими ядрами и с разделенными на потоки.
Остаётся ещё вопрос — числа потоков на ядро более чем два. Возможно ли это? И тут ответ однозначный — возможно. У IBM есть процессоры с 8 потоками на ядро прямо сейчас.
Вопрос актуальности 4-х потоков на ядро в обычных процессорах — стоит под вопросом. Я думаю, что разработчики процессоров имеют статистику по реальной занятости исполнительных устройств. И, учитывая, что 3-х или 4-х поточные ядра они не делают — означает, что, скорее всего, плотность занятости исполнительных устройств достаточно высокая; так что увеличение потоков в большей части задач будет ухудшать производительность из-за уменьшения удельного объема кеша на поток, или будет сильно снижать эффективность использования транзисторного бюджета, или усложнять внутренние передвижения инструкций и данных внутри конвейера.
Но не исключено, что кто-то из производителей пойдет на такой путь, допустим — увеличит число исполнительных устройств на ядро и вместо увеличения числа ядер чтобы занять все эти исполнительные устройства производители увеличат количество потоков на одно ядро. Вполне возможно, что этот путь может быть более рациональным, чем увеличения числа настоящих ядер. В таком случае кто-то из производителей к нему прибегнет.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.