Гипертрейдинг процессора как отключить
Обновлено: 06.07.2024
Отключение hyper-threading
MaximuS__87- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Электронная почта другу
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Электронная почта другу
Вообщем, делюсь методом. Распишу поподробнее, чтобы было понятно всем.
В общем все довольно незамысловато: есть программа CPU Control, которая распараллеливает целевую программу; для успешной её работы нужно, чтобы в окне программы CPU Control отображался как процесс самой программы, так и процесс целевой программы. Для целевой программы все просто: в диспетчере задач процессу потом зададим соответствие, а вот CPU Control должна запуститься с уже выставленными ядрами. Для этого используется программка imagecfg.exe. Далее по пунктам.
1. Качаем из любого источника маленькую программку (50кб) imagecfg.exe и копируем ее в любой каталог. Для удобства можно скопировать её в c:\\windows\system32 - это позволит запустить команду через "Пуск > Выполнить. " Можно сделать как я: в активном окне Total Commander войти в каталог, где лежит программа и вписать команду в командную строку внизу.
2. Установить CPU Control, например, в каталог "D:\CPU-Control\CPU_Control.exe". Можно запустить и убедиться, что в окне программы нет ни одного процесса. Тут же сразу делаем копию CPU_Control.exe, т.к. imagecfg изменит исполняемый .exe файл.
3. Теперь вводим в командную строку Total Commander или в окно "Пуск > Выполнить. " команду
imagecfg -a 0x0f "D:\CPU-Control\CPU_Control.exe" Должно появиться и пропасть черное окошко. После этого повторно запускаем CPU_Control.exe, в окне программы должен появиться процесс самой программы. Пока закрываем.
4. Теперь нужно запустить целевую программу и в диспетчере задач задать соответствие для её процесса. Выставляем 1, 2, 3 и 4 ядро, т.к. в команде для CPU Control было выставлено аналогичное соответствие (в команде это 0x0f).
5. После снова запускаем модифицированный CPU_Control.exe, в нем теперь видно оба процесса. Для того, чтобы целевая прога распараллелилась, нужно пару раз переключить справа режим на Авто, потом опять на ручной, чтобы напротив целевой программы были все единички (при необходимости правой кнопкой на процесс и выставить все ядра). Все. Теперь должно работать.
Опытным путем выяснил, что работают именно первые 4 ядра, если задать командой другие, процесс не отображается в окне CPU Control. Сначала хотел выставить 1, 3, 5, 7, но не вышло, видимо прога начинает подозревать, что ее обманывают, раз она видит ядра с больше CPU3 :). Если будет желание можете тоже попробовать, может заработает (если да, поделитесь). 0x0f указывает, что присвоить надо 1, 2, 3, 4 ядра. Привожу константы для всех:
0x01 = 1 = CPU0
0x02 = 2 = CPU1
0x04 = 4 = CPU2
0x08 = 8 = CPU3
0x10 = 16 = CPU4
0x20 = 32 = CPU5
0x40 = 64 = CPU6
0x80 = 128 = CPU7
0x0f = 15 = CPU0, CPU1, CPU2, and CPU3 (1+2+4+8 = 15)
Или, например: 0xc3 = 195 = CPU0, CPU1, CPU6, CPU7 (1+2+64+128)
Я пробовал на игре WOT, распараллелилось на 1 и 3 ядро, потоки 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 килобайт, поэтому существенно упала средняя скорость. Это не удивительно, каждое ядро имеет собственную кэш-память первого уровня, в то время, как логические процессоры одного ядра, используют ее совместно.
Если после предыдущих новостей о ZombieLoad вы в панике выясняете, как отключить функцию Intel Hyper-Threading, чтобы предотвратить использование новой уязвимости, похожей на Spectre и Meltdown, то сделайте глубокий выдох — официальное руководство Intel фактически не рекомендует делать это для большинства случаев.
ZombieLoad аналогична предыдущим атакам по «побочным каналам» (англ. side-channel attack), вынуждающим процессоры Intel открывать доступ к потенциально конфиденциальной информации, которая обычно изолирована и доступна только для использующих её приложений. Исследователи по безопасности сообщили ранее, что эта уязвимость присутствует в большинстве чипов Intel и может быть использована в Windows, MacOS и Linux.
ZombieLoad уже получила в Сети собственный логотип
Intel со своей стороны не согласна с тем, насколько серьёзным оценивается риск ZombieLoad. Компания даже решила дать ZombieLoad другое название — Microarchitectural Data Sampling (MDS) или Микроархитектурная выборка данных. Согласитесь, это звучит гораздо менее страшно, чем отсылка к каким-то зомби.
«Уязвимость MDS основана на выборке данных, просачивающихся из небольших структур в ЦП при использовании локально выполняемого побочного канала спекулятивного исполнения», — объясняют в компании. «Практическая эксплуатация MDS является очень сложным делом. Сама по себе уязвимость не предоставляет злоумышленнику способ выбрать те данные, которые он желает получить».
Так что насчёт Hyper-Threading?
Intel заявила, что отключение Hyper-Threading — не обязательный и не единственный вариант для пользователей ПК. На самом деле, по словам Intel, каждый клиент сам решает, что ему делать. Если вы не можете гарантировать безопасность установленного у вас программного обеспечения, тогда да, вероятно, отключить Hyper-Threading — это хорошая идея. Если же программное обеспечение поставляется только из магазина Microsoft, из ИТ-отдела или просто установлено из доверенных, по вашему мнению, источников, вы, вероятно, можете оставить Hyper-Threading включенным. Всё действительно зависит только от того, насколько вы переживаете о своей безопасности.
«Поскольку факторы значительно различаются для разных клиентов, Intel не рекомендует отключать Hyper-Threading, так как важно понимать, что это — не единственный путь обеспечить защиту от MDS и не обеспечивает защиту само по себе», — говорится в заявлении компании.
В то же время реакция производителей операционных систем отличается друг от друга.
Google выпустил исправление для Chrome OS, которое по умолчанию отключает Hyper-Threading для Chromebook. Люди, которые хотят включить технологию мультипоточности обратно, могут сделать это самостоятельно, считают в компании.
Apple выпустила обновление для MacOS Mojave и сообщила, что клиенты компании, особенно требовательные к безопасности, могут отключить Hyper-Threading самостоятельно.
Microsoft заявила, что выпустила патчи для своего программного обеспечения, чтобы сократить вероятность использования MDS, но также отметила, что клиенты должны дополнительно получить обновление прошивок от своих производителей ПК.
В связи с тем, что по большей части поставщики операционных систем решили оставить Hyper-Threading включённым, угроза ZombieLoad, очевидно, не так серьёзна, как это казалось ещё сутки назад. К тому же, до сих пор нет ни одного известного случая использования уязвимости в реальной атаке.
При этом использование патчей без отключения технологии Hyper-Threading почти не снижает производительность процессоров Intel.
Intel демонстрирует, что частичное исправление уязвимости без отключения Hyper-Threading почти не влияет на производительность
Но вы не поверите, если посмотрите на результаты тестирования Intel влияния патчей безопасности на производительность при отключенном Hyper-Threading. Компания утверждает, что исправления безопасности вместе с отключением Hyper-Threading оказывают подозрительно небольшое влияние на производительность.
Результаты тестирования исправления безопасности при отключенном Hyper-Threading
Портал PCWorld категорически не согласен с мнением Intel о том, что отключение Hyper-Threading не представляет особой проблемы, хотя Intel и демонстрирует в своём документе, что производительность практически не изменилась. Проблема состоит в искусственности тестов Intel при отключении Hyper-Threading, поскольку компания не тестировала специфичные многопоточные нагрузки. Если бы Intel взяла тесты Blender, Cinebench или другие, рассчитанные на многоядерные и многопоточные процессоры, мы бы сразу увидели мощный провал в быстродействии.
Чтобы подчеркнуть, насколько важна технология Hyper-Threading, можно просто посмотреть на процессоры Intel i9-9900K за $500 и i7-9700K за $375, главное отличие которых заключается как раз в поддержке Hyper-Threading. Отключение Hyper-Threading на процессорах Intel — это невероятный удар для всех, кому важна многопоточная производительность.
Как стало недавно известно, были обнаружены четыре новых аппаратных уязвимости, затрагивающие процессоры Intel. Эти новые «дыры» позволяют злоумышленникам получить доступ к данным пользователя, используя уязвимости стороннего канала – MDS (Microarchitectural Data Sampling), наиболее серьёзной из которых является, наверное, «ZombieLoad».
В отличие от предыдущих ошибок, основанных на спекулятивном исполнении команд, частично затронувших AMD и Arm-процессоры, ошибки MDS относятся исключительно к чипам Intel. Свести риск от этих уязвимостей можно не дожидаясь патчей и обновлений, отключив одновременную многопоточность (SMT), она же – «Hyper-Threading» у Intel.
В настоящее время Microsoft готовит обновление Windows 10 1903, которое призвано устранить четыре уязвимости MDS. Но полностью это проблему не решает, нужны также обновления в BIOS и, как сообщается, Intel уже выпустила новый микрокод для партнеров-производителей материнских плат. Однако на момент написания этой статьи не было выпущено ни одной новой версии BIOS. Мы решили протестировать худший вариант сценария, отключив Hyper-Threading. Это может оказаться единственным решением для старых компьютеров, поскольку вряд ли производители выпустят патчи для всех моделей.
Сегодня мы посмотрим, как влияет отключение Hyper-Threading на процессоры Intel, поддерживающие эту функцию. Мы уже делали это в прошлом, и это интересный тест, но теперь у нас есть повод взглянуть на результаты более критично, учитывая, что новая уязвимость безопасности в процессорах Intel связана с SMT.
Для теста мы выбрали процессоры Core i7-8700K и 7700K, протестировав их работу в ряде игр и приложений при включенной и отключенной функции Hyper-Threading. Восьмиядерный i9-9900K мы не стали брать, поскольку в нем недостающие потоки не приведут к потере производительности в играх, хотя в приложениях всё-таки соответствующее негативное влияние будет заметно в той же степени, как у 8700K и 7700K.
Если бы у нас было больше времени (мы сейчас готовимся к Computex 2019, так что следите за нашими обновлениями), мы бы хотели также протестировать некоторые двухъядерные процессоры Intel с поддержкой Hyper-Threading, поскольку в них влияние этой функции, несомненно, будет наиболее значительным. Хотя, можно обойтись результатами наших предыдущих тестов этой технологии.
Все тесты выполнялись на компьютере, оснащенном 32 ГБ памяти DDR4-3200, видеокартой GeForce RTX 2080 Ti (чтобы предотвратить боттлнеки на GPU) и Windows 10 build 1903. Игровые тесты проводились как в разрешении 1080p, так и в 1440p, но начнём мы с тестов приложений.
Тесты приложений
Прежде всего, мы получили результаты Cinebench R20 и, глядя на Core i7-8700K, видим снижение производительности на 24% при отключенной Hyper-Threading. Разумеется, такое снижение производительности не останется незамеченным. Более того, мы тем самым фактически превратили 8700K в 7700K по части производительности.
Между тем 7700K становится на 26% медленнее с отключенной Hyper-Threading, и теперь у нас есть старый четырехъядерник или Core i5 поколения Kaby Lake. Для приложений, которые активно используют все ядра, отключение SMT/Hyper-Threading сильно влияет на производительность.
WinRAR ощущает значительную потерю производительности – на 36% у 8700K. Очевидно, что Hyper-Threading отлично себя показывает в этом типе рабочей нагрузки. Столь же сильное падение мы видим и у 7700K – 39%.
Corona – высокопроизводительный рендер, и здесь 8700K показал снижение производительности на 31% при отключении Hyper-Threading, в то время как у 7700K – 33%. В обоих случаях снижение производительности велико, и это позволит нам оценить работу устраняющих уязвимость обновлений, при выполнении задач рендеринга и кодирования.
Blender также испытывает серьёзную потерю производительности при отключении Hyper-Threading, хоть и несколько меньше, чем Corona – на 25% для 8700K, т.е. примерно как Cinebench R20. Из-за меньшего количества ядер, 7700K страдает несколько больше, и здесь мы видим снижение производительности на 29%.
Потребляемая мощность
Прежде чем перейти к играм, мы бы хотели отметить общее энергопотребление системы. Да, мы не видим потребление отдельно процессоров, поэтому трудно что-то говорить об эффективности, но, как вы можете видеть, отключение Hyper-Threading на 8700K не приводит к весомой экономии энергии, уменьшая общее энергопотребление системы лишь на
5%. В то же время отключение Hyper-Threading на 7700K приводит уже к 11% экономии энергии, и мы это связываем с тем, что четырёхядерный 7700K использует данную функцию более активно, чем шестиядерный 8700K.
Тестирование в играх
Начнём с результатов Assassin's Creed: Odyssey на разрешении 1080p. На 8700K значение средней частоты кадров сократилось лишь на 13%, а минимальной (1%) – не изменилось. С другой стороны, 7700K показал значительное падение как средней частоты кадров, так и 1%-минимальной – 23% и 21% соответственно. Владельцы четырёхъядерных процессоров гораздо сильнее ощутят снижение производительности при отключении Hyper-Threading.
А теперь мы видим, что если на 1440p приоритет управления у вас берет на себя видеокарта, 8700K отлично справляется с отключенной функцией Hyper-Threading, как раз благодаря RTX 2080 Ti. Для четырехъядерных и, не дай бог, двухъядерных процессоров, любое ограничение Hyper-Threading приведет к потере производительности.
Battlefield V – весьма требовательная к ресурсам процессора игра, правда нам удалось протестировать только однопользовательский режим, да и то потребовалось два аккаунта Origin из-за системы блокировки аккаунтов при изменении конфигурации. Возвращаясь к теме, мы опять же не видим значительного снижения производительности здесь. Наибольший спад составил 12%, если смотреть на 1%-минимальное значение FPS у 7700K.
Увеличение разрешения до 1440p не улучшило ситуацию с минимальным FPS, и мы видим, что в обоих случаях отключение Hyper-Threading действительно снижает производительность, хотя этот разрыв уже не так велик, как при рабочих нагрузках.
У Division 2 результаты – жесть. Взгляните, как упала производительность у 7700K при отключении Hyper-Threading. Средняя частота кадров снижается на 37%, а минимальная 1% – на 38%, что близко к результатам, показанным WinRAR.
Да, влияние на производительность 6-ядерного 8700K не столь велико, но даже при этом падение минимального FPS на 13% большинство игроков не оценят. Переходим на 1440p, и теперь 8700K даже с отключенным Hyper-Threading не является фактором ограничения производительности, его теперь берёт на себя RTX 2080 Ti. Однако мы по-прежнему наблюдаем падение производительности на треть у 7700K, глядя на минимальный 1% FPS у него.
Небольшая ремарка. Far Cry New Dawn чувствует себя лучше на 9700K, чем на 8700K. Средняя частота кадров на 9700K достигает
120 при 1080p. Но мы бы хотели заметить, что когда мы отключаем Hyper-Threading у 8700K, он соответствует 9700K в этом тесте, из чего следует, что количество потоков не идёт на пользу этой игре, так что 6 ядер/6 потоков для неё в целом более эффективен, чем 6 ядер/12 потоков. Но подобных игр очень немного.
Как видим, 7700K с меньшим количеством ядер не страдает такой проблемой при включении Hyper-Threading, хотя он всё-ж был чуточку быстрее с отключенным. Так что, это одна из немногих игр, для которых отключение Hyper-Threading вообще не проблема, и на самом деле идёт на пользу. При условии, если у вас не двухядерный процессор, конечно.
Переключаемся на 1440p, и видим, что количество ядер здесь вообще ничего не решает, а Hyper-Threading лишь замедляет оба процессора.
Далее у нас Hitman 2, и здесь мы видим, что отключение Hyper-Threading не оказывает существенного влияния на 8700K, однако для четырехъядерного 7700K оно сокрушительно. Средняя частота кадров снизилась на 18%, но гораздо хуже, что 1%-минимальный FPS упал почти на 30%. Конечно, мы все еще видим стабильные 60+ кадров в секунду, но для тех, кто любит большой FPS, такой удар по производительности является жёстким.
Следующей игрой идёт Rage 2, где отключение Hyper-Threading практически не оказывает влияния на 8700K. У 7700K средняя частота кадров также почти не меняется, но зато минимальный 1% FPS падает весьма значительно – на 20%.
Стоит только увеличить разрешение до 1440p в Rage 2, и процессор перестаёт быть компонентом, ограничивающим производительность. По крайней мере, если смотреть на 7700K без Hyper-Threading. Так что в данном случае отключение Hyper-Threading не оказывает влияния на производительность.
Мы с вами уже убеждались ранее, насколько Shadow of the Tomb Raider может быть требовательным, и здесь мы в этом убедимся ещё раз. У 8700K наблюдаем падение среднего FPS на 10-12% при отключении Hyper-Threading, а у 7700K – вдвое большее, на 24%. Однако ухудшение значения минимального 1% FPS для обоих процессоров одинаковое. В любом случае отключение SMT оказывает сильное влияние на эту игру.
Даже при переходе на 1440p негативный эффект значительный, по крайней мере для 7700K. У 8700K все еще наблюдается небольшое снижение производительности, но это ничто по сравнению с 20%-м падением у 7700K.
Ну и напоследок – World War Z, использующая низкоуровневый API Vulkan. Эта игра прекрасно работает с 4 ядрами, поэтому ни один из процессоров не страдает при отключении Hyper-Threading. Нечто подобное мы видим и при разрешении 1440p, поскольку оба процессора способны извлечь максимальную производительность из RTX 2080 Ti.
Резюме
Мы теперь имеем неплохое представление о том, как 4- и 6-ядерные процессоры Intel работают с включенной Hyper-Threading по сравнению с отключенной. Если кратко, то производительность приложений при выполнении основных ресурсоемких операций обычно снижалась от 25 до 35%.
Влияние на производительность в играх может существенно различаться в зависимости от самой игры и других факторов, таких как разрешение, настройки графики и, конечно, установленная видеокарта. В тестируемых нами играх, 6-ядерный процессор Intel демонстрирует в основном минимальное влияние на свою производительность, хотя минимальный 1% FPS иногда заметно страдает, и при игре с высокой частотой обновления падение производительности будет весьма ощутимым.
Владельцы процессоров с топологией 8/16, таких как 9900K, практически не заметят никакого влияния Hyper-Threading во время игр, но падение производительности приложений по-прежнему будет сильным – на 25-35% без SMT. С другой стороны, наиболее существенное снижение производительности испытают на себе менее мощные процессоры, которые в гораздо большей степени полагаются на Hyper-Threading. Даже наш четырехъядерный 7700K зачастую демонстрировал значительную потерю производительности в игровых тестах, и это означает, что для владельцев двухъядерных процессоров с поддержкой SMT отключение Hyper-Threading будет еще более болезненным.
На данный момент трудно с уверенностью сказать, какое влияние на производительность окажут программные средства для смягчения риска от четырёх уязвимостей MDS на компьютерах под управлением Windows, но мы можем ожидать, что будут определенные потери, особенно там, где Hyper-Threading оказывает наибольшее влияние. Phoronix протестировал эти программные средства в Linux, и показатели потери производительности варьируются от незначительных до огромных. Кроме того, Phoronix обнаружил, что системы Intel теперь на
16% медленнее, чем раньше, до установки программного смягчения воздействий Spectre, Meltdown, Foreshadow и Zombieload. В то время как системы AMD показали снижение производительности всего на 3%. Они также утверждают, что таких мер по уменьшению риска достаточно, чтобы приблизить Core i7-8700K к Ryzen 7 2700X и Core i9-7980XE к Threadripper 2990WX.
Если Intel не вытащит кролика из шляпы и не предоставит действительно эффективных программных решений, таких, чтобы можно было бы не отключать Hyper-Threading, то владельцев двух- и четырехъядерных процессоров Intel с поддержкой Hyper-Threading могут ожидать неутешительные последствия. В списке таких процессоров: Core i3 и Core i5 – от Clarkdale до Kaby Lake; все Core i7 вплоть до Kaby Lake; а также процессоры Kaby Lake и Coffee Lake семейства Pentium.
Тем, кто довольствуется более старым оборудованием и не выполняет никаких критически важных задач, до момента явного обнаружения атаки на MDS-эксплойтах, лучшим вариантом сохранить производительность будет, вероятно, отказ от установки обновлений против таких атак. Это не является нашей официальной рекомендацией, а лишь интересная мысль по поводу того, какими могут быть альтернативные пути решения проблемы после выпуска соответствующих обновлений.
В этой статье мы провели интересное исследование того, где функция Hyper-Threading оказывает наибольшее влияние. В ней мы отразили последствия наихудшего сценария, когда SMT приходится полностью исключить, но в свою очередь мы наблюдаем и некоторые движения в направлении не допустить такого сценария. Google отключил Hyper-Threading в Chrome OS, сообщество OpenBSD рекомендует сделать то же самое, в то время как Apple частично пропатчила системы средствами снижения риска проникновения эксплойтов и сообщила, что для полного устранения риска от уязвимостей необходимо отключить Hyper-Threading. Другие производители, такие как Microsoft, еще не заняли определенную позицию.
Читайте также: