Что такое гипертрейдинг процессора

Повышенная производительность для многих бизнес-приложений

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

Технология Intel® Hyper-Threading реализована в новейших процессорах Intel® Core™ vPro™, семействе процессоров Intel® Core™, семействе процессоров Intel® Core™ M и семействе процессоров Intel® Xeon®. При использовании одного из этих процессоров Intel® вместе с набором микросхем, а также операционной системы и BIOS с поддержкой технологии Intel® Hyper-Threading можно получить следующие преимущества.

Превосходная графика без компромиссов

Технология Intel® Hyper-Threading позволяет энтузиастам мультимедийных технологий создавать, редактировать и кодировать файлы с большим объемом графических данных при параллельной работе нескольких фоновых приложений, таких как антивирусные программы, без ущерба для производительности системы.

Чем больше задач, тем выше эффективность работы

Процессоры с одновременной поддержкой технологий Intel® Hyper-Threading и Intel® Turbo Boost (или Intel® Turbo Boost 2.0, реализованной в новейших процессорах Intel® Core™ i5 и более производительных процессорах), обеспечивают более высокую производительность и увеличивают скорость выполнения задач. Такое сочетание технологий позволяет одновременно обрабатывать несколько потоков, динамически адаптироваться к нагрузке и автоматически отключать неактивные ядра. Это повышает тактовую частоту процессора в задействованных ядрах, обеспечивая еще большую производительность для многопоточных приложений.

Благодаря технологии Intel® Hyper-Threading предприятия получают следующие возможности:

Оценка готовности системы

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

Источник

Еще раз о Hyper Threading

Некоторое время назад автор позволил себе «слегка поворчать» по поводу новой парадигмы от Intel — Hyper Threading. К чести корпорации Intel, недоумение автора не осталось ею незамеченной. А посему автору предложили помощь в выяснении (как деликатно дали оценку менеджеры корпорации) «настоящей» ситуации с технологией Hyper Threading. Ну что же — желание выяснить истину можно только похвалить. Не так ли, уважаемый читатель? По крайней мере, именно так звучит одна из прописных истин: правда — это хорошо. Что ж, будем стараться действовать в соответствии с данной фразой. Тем более, что действительно появилось некоторое количество новых сведений.

Для начала сформулируем, что же именно мы знаем про технологию Hyper Threading:

1. Данная технология предназначена для увеличения эффективности работы процессора. Дело в том, что, по оценкам Intel, большую часть времени работает всего 30% (кстати, достаточно спорная цифра — подробности ее вычисления неизвестны) всех исполнительных устройств в процессоре. Согласитесь, это достаточно обидно. И то, что возникла идея каким-то образом «догрузить» остальные 70% — выглядит вполне логично (тем более что сам по себе процессор Pentium 4, в котором и внедрят эту технологию, отнюдь не страдает от избыточной производительности на мегагерц). Так что эту идею автор вынужден признать вполне здравой.

2. Суть технологии Hyper Threading состоит в том, что во время исполнения одной «нити» программы простаивающие исполнительные устройства могут заняться исполнением другой «нити» программы (или «нити» другой программы). Или, например, исполняя одну последовательность команд, ожидать данных из памяти для исполнения другой последовательности.

3. Естественно, выполняя различные «нити», процессор должен каким-либо образом отличать, какие команды к какой «нити» относятся. Значит, есть какой-то механизм (некая метка), благодаря которой процессор отличает, к какой «нити» относятся команды.

5. Также известно, что в случае, когда несколько «нитей» претендуют на одни и те же ресурсы, либо одна из «нитей» ждет данных — во избежание падения производительности программисту необходимо вставлять специальную команду — «pause». Естественно, это потребует очередной перекомпиляции программ.

6. Также понятно, что возможны ситуации, когда попытки одновременного исполнения нескольких «нитей» приведут к падению производительности. Например, из-за того, что размер кэша L2 не бесконечный, а активные «нити» будут пытаться загрузить кэш — возможна ситуация, когда такая «борьба за кэш» приведет к постоянной очистке и перезагрузке данных в кэше второго уровня.

7. Intel утверждает, что при оптимизации программ под данную технологию выигрыш будет составлять до 30%. (Вернее, Intel утверждает, что на сегодняшних серверных приложениях и сегодняшних системах измеренный выигрыш до 30%) Гм…. Это более чем достаточный стимул для оптимизации.

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

У автора сложилось впечатление (возможно, ошибочное), что в данном случае имеется ввиду программный фрагмент, который мультизадачная операционная система назначает на исполнение одному из процессоров мультипроцессорной аппаратной системы. «Постойте!» — заявит внимательный читатель — «это же одно из определений! Что тут нового?». А ничего — в данном вопросе автор на оригинальность не претендует. Разобраться бы, что «наоригинальничала» Intel :-). Ну что же — примем в качестве рабочей гипотезы.

Далее — исполняется некоторая нить. Тем временем декодер команд (кстати, полностью асинхронный и не входящий в пресловутые 20 стадий Net Burst) осуществляет выборку и дешифрацию (со всеми взаимозависимостями) в микроинструкции. Здесь надо пояснить, что автор подразумевает под словом «асинхронный» — дело в том, что результат «разваливания» х86 команд в микроинструкции происходит в блоке дешифрации. Каждая команда х86 может быть декодирована в одну, две, или более микроинструкций. При этом на стадии обработки выясняются взаимозависимости, доставляются необходимые данные по системной шине. Соответственно, скорость работы этого блока часто будет зависеть от скорости доступа данных из памяти — и в худшем случае определяется именно ею. Было бы логично «отвязать» его от того конвейера, в котором, собственно, и происходит выполнение микроопераций. Это было сделано путем помещения блока дешифрации перед trace cache. Чего мы этим добиваемся? А добиваемся мы при помощи такой «перестановки блоков» местами простой вещи — если в trace cache есть микроинструкции для исполнения — процессор работает более эффективно. Естественно, этот блок работает на частоте процессора — в отличие от Rapid Engine. Кстати, у автора сложилось впечатление, что данный декодер представляет собой нечто вроде конвейера длиной до 10–15 стадий. Таким образом, от выборки данных из кэша до получения результата проходит, по всей видимости, порядка 30 — 35 стадий (включая конвейер Net Burst, см. Microdesign Resources August2000 Microprocessor report Volume14 Archive8, page12).

Полученный набор микроинструкций вместе со всеми взаимозависимостями накапливается в trace cache — в том самом, который приблизительно 12 000 микроопераций. По приблизительным оценкам источник такой оценки — строение микроинструкции P6; дело в том, что принципиально длина инструкций вряд ли кардинально поменялась (считая длину микроинструкции вместе со служебными полями порядка 100 бит) размер trace cache получается от 96 КБ до 120 КБ. Однако! На фоне этого кэш данных размером 8 КБ выглядит как-то несимметрично :-)… и бледно. Конечно, при увеличении размера увеличиваются задержки доступа (к примеру, при увеличении до 32КБ задержки вместо двух тактов составят 4). Но неужели так важна скорость доступа в этот самый кэш данных, что увеличение задержки на 2 такта (на фоне общей длины всего конвейера) делает такое увеличение объема невыгодным? Или дело просто в нежелании увеличивать размер кристалла? Но тогда при переходе на 0.13 мкм первым делом стоило увеличить именно этот кэш (а не кэш второго уровня). Сомневающимся в данном тезисе стоило бы припомнить переход с Pentium на Pentium MMX — благодаря увеличению кэша первого уровня вдвое практически все программы получали 10 — 15% прироста производительности. Что же говорить об увеличении вчетверо (особенно учитывая, что скорости процессоров выросли до 2ГГц, а коэффициент умножения — с 2.5 до 20)? По неподтвержденным данным, в следующей модификации ядра Pentium4 (Prescott) кэш первого уровня таки увеличат до 16 или 32 КБ. Также увеличится кэш второго уровня. Впрочем, на сегодняшний момент все это не более чем слухи. Откровенно говоря, слегка непонятная ситуация. Хотя — оговоримся — автор вполне допускает, что подобной идее мешает некая конкретная причина. Как пример — подойдут некие требования по геометрии расположения блоков или банальная нехватка свободного места вблизи конвейера (ясно ведь, что необходимо расположить кэш данных поближе к ALU).

Не отвлекаясь, смотрим на процесс дальше. Конвейер работает — пусть нынешние команды задействуют ALU. Ясно, что FPU, SSE, SSE2 и прочие при этом простаивают. Не тут-то было — вступает в действие Hyper Threading. Заметив, что готовы микроинструкции вместе с данными для новой нити, блок переименования регистров выделяет новой нити порцию физических регистров. Кстати, возможны два варианта — блок физических регистров общий для всех нитей, или же отдельный для каждого. Судя по тому, что в презентации Hyper Threading от Intel в качестве блоков, которые надо изменять, блок переименования регистров не указан — выбран первый вариант. Это хорошо или плохо? С точки зрения технологов — явно хорошо, ибо экономит транзисторы. С точки зрения программистов — пока неясно. Если количество физических регистров действительно 128, то при любом разумном количестве нитей ситуации «нехватка регистров» возникнуть не может. Затем они (микроинструкции) отправляются в планировщик, который, собственно, направляет их на исполнительное устройство (если оно не занято) или «в очередь», если данное исполнительное устройство сейчас недоступно. Таким образом, в идеале достигается более эффективное спользование имеющихся исполнительных устройств. В это время сам процессор с точки зрения ОС выглядит как два «логических» процессора. Гм… Неужели все так безоблачно? Давайте присмотримся к ситуации: часть оборудования (как-то кэши, Rapid Engine, модуль предсказания переходов) являются общими для обоих процессоров. Кстати, точность предсказания переходов от этого, скорее всего, слегка пострадает. Особенно, если исполняемые одновременно нити не связаны друг с другом. А часть (например, MIS [Microcode Instruction Sequencer] — планировщик последовательности микрокоманд — подобие ПЗУ, содержащее набор заранее запрограммированных последовательностей обычных операций и RAT [Register Alias Table] — таблица переименования [псевдонимов] регистров) блоков должна отличать различные нити, запущенные на «разных» процессорах. Попутно (из общности кэша) следует, что, если две нити являются «жадными» к кэшу (то есть увеличение кэша дает большой эффект), то применение Hyper Threading способно даже снизить скорость. Это происходит потому, что на сегодняшний момент реализован «конкурентный» механизм борьбы за кэш — «активная» в данный момент нить вытесняет «неактивную». Впрочем, механизм кэширования, по-видимому, может измениться. Также понятно, что скорость (по крайней мере, на текущий момент) будет снижаться в тех приложениях, в которых она снижалась и в честном SMP. Как пример — SPEC ViewPerf обычно на однопроцессорных системах показывает более высокие результаты. А посему наверняка на системе с Hyper Threading результаты будут меньше, чем без нее. Собственно, результаты практического тестирования Hyper Threading можно посмотреть по этому адресу.

1. Ясно, что конвейер «шириной» 16 разрядов разгонять легче, чем шириной 32 разряда — просто по причине наличия перекрестных помех и К о

2. По-видимому, Интел счел операции целочисленного вычисления достаточно часто встречающимися, чтобы ускорять именно ALU, а не, скажем, FPU. Вероятно, при вычислении результатов целочисленных операций используются либо таблицы, либо схемы «с накоплением переноса». Для сравнения, одна 32-битная таблица это 2E32 адресов, т.е. 4гигабайта. Две 16-разрядные таблицы это 2х64кб или 128 килобайт — почувствуйте разницу! Да и накопление переносов в двух 16-разрядных порциях происходит быстрее, чем в одной 32-разрядной.

3. Экономит транзисторы и… тепло. Ведь ни для кого не секрет, что все эти архитектурные ухищрения греются. По видимому, это была достаточно большая (а, возможно, и главная) проблема — чего стоит, к примеру, Thermal Monitor как технология! Ведь необходимости в подобной технологии как таковой не очень много — то есть, конечно, приятно, что она есть. Но давайте говорить честно — простой блокировки хватило бы для достаточной надежности. Раз такая сложная технология была предусмотрена — значит, всерьез рассматривался вариант, когда подобные изменения частоты на ходу были одним из штатных режимов работы. А, может, основным? Ведь не зря ходили слухи, что Pentium 4 задумывался с гораздо большим количеством исполнительных устройств. Тогда проблема тепла должна была стать просто основной. Вернее, по тем же слухам, тепловыделение должно было составить до 150 Вт. А тогда очень логично принять меры к тому, чтобы процессор работал «в полную силу» только в таких системах, где обеспечено нормальное охлаждение. Тем более, что большинство корпусов «китайского» происхождения продуманностью конструкции с точки зрения охлаждения отнюдь не блещут. Гм…. Далековато забрались 🙂

Но все это теоретизирования. Есть ли сегодня процессоры, в которых применяется эта технология? Есть. Это Xeon (Prestonia) и XeonMP. Причем, интересно, что XeonМР от Xeon отличается поддержкой до 4 процессоров (чипсеты типа IBM Summit поддерживают до 16 процессоров, методика приблизительно такая же, как и в чипсете ProFusion) и наличием кэша третьего уровня объемом 512 КБ и 1 МБ, интегрированного в ядро. Кстати, а почему интегрировали кэш именно третьего уровня? Почему не увеличен кэш первого уровня? Должна же быть какая-то разумная причина…. Почему не увеличили кэш второго уровня? Возможно, причина в том, что Advanced Transfer Cache нуждается в относительно небольших задержках. А увеличение объема кэша приводит к увеличению задержек. Посему кэш третьего уровня для ядра и кэша второго уровня вообще «представляется» как шина. Просто шина :-). Так что прогресс налицо — сделано все, чтобы данные подавались в ядро как можно быстрее (а, попутно, поменьше загружалась шина памяти).

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

Интересно, будет ли развиваться идея Hyper Threading? Дело в том, что в количественном отношении ей развиваться особо некуда — понятно, что два физических процессора лучше трех логических. Да и позиционировать будет нелегко…. Интересно, что Hyper Threading может пригодиться и при интегрировании двух (или более) процессоров на кристалл. Ну а под качественными изменениями автор имеет ввиду, что наличие такой технологии в обычных десктопах приведет к тому, что фактически большинство пользователей будут работать на [почти] двухпроцессорных машинах — что очень хорошо. Хорошо потому, что подобные машины работают не в пример «плавнее» и «отзывчивее» на действия пользователя даже под большой нагрузкой. Сие, с точки зрения автора, есть весьма хорошо.

Вместо послесловия

Автор должен признаться, что в течение работы над статьей его отношение к Hyper Threading неоднократно менялось. По мере того, как собиралась и обрабатывалась информация — отношение становилось то в целом положительным, то наоборот :-). На сегодняшний момент можно написать следующее:

есть только два способа повышать производительность — повышать частоту, и повышать производительность за такт. И, если вся архитектура Pentium4 рассчитана на первый путь, то Hyper Threading — как раз второй. Уже с этой точки зрения ее можно только приветствовать. Так же Hyper Threading несет несколько интересных следствий, как-то: изменение парадигмы программирования, привнесение многопроцессорности в массы, увеличение производительности процессоров. Однако, на этом пути есть несколько «больших кочек», на которых важно не «застрять»: отсутствие нормальной поддержки со стороны операционных систем и, самое главное, необходимость перекомпиляции (а в некоторых случаях и смены алгоритма) приложений, чтобы они в полной мере смогли воспользоваться преимуществами Hyper Threading. К тому же, наличие Hyper Threading сделало бы возможной действительно параллельную работу операционной системы и приложений — а не «кусками» по очереди, как сейчас. Конечно, при условии, что хватит свободных исполнительных устройств.

Источник

Технология Intel Hyper-Threading — что это и как работает

Впервые технология Hyper-Threading (HT, гиперпоточность) появилась 15 лет назад — в 2002 году, в процессорах Pentium 4 и Xeon, и с тех пор то появлялась в процессорах Intel (в линейке Core i, некоторых Atom, в последнее время еще и в Pentium), то исчезала (ее поддержки не было в линейках Core 2 Duo и Quad). И за это время она обросла мифическими свойствами — дескать ее наличие чуть ли не удваивает производительность процессора, превращая слабые i3 в мощные i5. При этом другие говорят что HT — обычная маркетинговая уловка, и толку от нее мало. Правда как обычно по середине — местами толк от нее есть, но двухкртаного прироста ждать точно не стоит.

Техническое описание технологии

Начнем с определения, данного на сайте Intel:

Допустим перед процессором стоят две задачи. Если процессор имеет одно ядро, то он будет выполнять их последовательно, если два — то параллельно на двух ядрах, и время выполнения обеих задач будет равно времени, затраченному на более тяжелую задачу. Но что если процессор одноядерный, но поддерживает гиперпоточность? Как видно на картинке выше при выполнении одной задачи процессор не занят на 100% — какие-то блоки процессора банально не нужны в данной задаче, где-то ошибается модуль предсказания переходов (который нужен для предсказания, будет ли выполнен условный переход в программе), где-то происходит ошибка обращения к кэшу — в общем и целом при выполнении задачи процессор редко бывает занят больше, чем на 70%. А технология HT как раз «подпихивает» незанятым блокам процессора вторую задачу, и получается что одновременно на одном ядре обрабатываются две задачи. Однако удвоения производительности не происходит по понятным причинам — очень часто получается так, что двум задачам нужен один и тот же вычислительный блок в процессоре, и тогда мы видим простой: пока одна задача обрабатывается, выполнение второй на это время просто останавливается (синие квадраты — первая задача, зеленые — вторая, красные — обращение задач к одному и тому же блоку в процессоре):

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

Плюсы и минусы технологии

С учетом того, что кристалл процессора с поддержкой HT физчески больше кристалла процессора без HT в среднем на 5% (именно столько занимают дополнительные блоки регистров и контроллеры прерываний), а поддержка HT позволяет нагрузить процессор на 90-95%, то в сравнении с 70% без HT мы получаем, что прирост в лучшем случае будет 20-30% — цифра достаточно большая.

Программы, плохо работающие с гиперпоточностью

Традиционно это большинство игр — их обычно бывает трудно грамотно распараллелить, поэтому зачастую четырех физических ядер на высоких частотах (i5 K-серии) более чем хватает для игр, распараллелить которые под 8 логических ядер в i7 оказывается непосильной задачей. Однако стоит учитывать и то, что есть фоновые процессы, и если процессор не поддерживает HT, то их обработка ложится на физические ядра, что может замедлить игру. Тут i7 с HT оказывается в выигрыше — все фоновые задачи традиционно имеют пониженный приоритет, поэтому при одновременной работе на одном физическом ядре игры и фоновой задаче игра будет получать повышенный приоритет, и при этом фоновая задача не будет «отвлекать» занятые игрой ядра — именно поэтому для стриминга или записи игр лучше брать i7 с гиперпоточностью.

Итоги

Пожалуй тут остается только один вопрос — так имеет ли смысл брать процессоры с HT или нет? Если вы любите держать одновременно открытыми пяток программ и при этом играть в игры, или же занимаетесь обработкой фото, видео или моделированием — да, разумеется стоит брать. А если вы привыкли перед запуском тяжелой программы закрывать все другие, и не балуетесь обработкой или моделированием, то процессор с HT вам ни к чему.

Источник

Что такое SMT (Hyper-Threading) — плюсы и минусы

Пока я радую свои графоманские пристрастия написанием детальной технической статьи про «Windows Performance Station», захотелось поделиться своими мыслями о том, что хорошего и плохого приносит SMT в процессоры «AMD» и «Intel», и как тут поможет «Windows Performance Station».

Тем, кому интересна данная тема, добро пожаловать под кат…

Итак, для начала давайте определимся, что такое SMT.

Как говорит нам википедия, SMT (от англ. simultaneous multithreading) это одновременная многопоточность, т.е. несколько потоков выполняются одновременно, а не последовательно, как это происходит во «временной многопоточности».

Многие знают эту технологию под названием «Intel Hyper-Threading», про неё уже всё давно написано, но до сих пор я сталкиваюсь с тем что многие разработчики, и, тем более, обыватели не понимают в чём основная суть «одновременного» выполнения нескольких команд одним ядром процессора и какие проблемы это несёт.

Для начала поговорим про временную многопоточность.

До реализации технологии SMT в виде «Hyper-Threading» использовалась технология «временной многопоточности».

Тут всё просто, представим, что у нас есть один конвейер и один рабочий (Ядро ЦП), который выполняет операции над числами и записывает результат. Предположим, для этих операций ему нужна отвёртка и гаечный ключ. Операционная система (ОС) складывает нашему рабочему на конвейер по порядку одну операцию для отвёртки, а за ней одну операцию для гаечного ключа. Один рабочий в один момент времени может оперировать или только гаечным ключом или только отвёрткой. Таким образом, выкладывая разное количество разных блоков, ОС определяет приоритет выполнения тех или иных операций от разных приложений. Пропорцию одних блоков к другим мы можем указывать внутри ОС, когда указываем приоритет процесса. Именно это и делают все диспетчеры задач в т.ч. и «Windows Performance Station». Это приоритизирование распространяется далее на механизмы SMT и всю работу с конвейерами.

С появлением SMT ситуация становится чуть сложнее.

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

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

Исходя из этого, когда на конвейере находится операция (A и B) с одной стороны и (D и E) с другой стороны — всё отлично, но при распараллеливании цепочки вычислений могут получиться две проблемы:

1. С одной стороны конвейера оказалось действие (A и B) = С, а с другой (D и E) = C,

т.е. нужно записать сначала одно значение C, а потом второе значение C, но не одновременно (конфликт по управлению).

2. С одной стороны конвейера оказалось действие (A и B) = C, а с другой (A и C) = D,

т.е. нужно сначала посчитать C, а потом посчитать D, но не одновременно (конфликт по данным).

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

Предсказатель переходов, как понятно из названия, осуществляет предсказание 🙂

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

В свою очередь, кэш процессора, необходим для быстрого решения второй проблемы, когда мы останавливаем решение выражения (A и C) = D и пишем в кэш результат выполнения (A и B) = C, после чего сразу вычисляем (A и C) = D.

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

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

Вообще, стоит держать в уме, что «Intel» разработала «Hyper-Threading» одновременно с созданием своих первых многоядерных процессоров «Xeon» и, по сути, эту технологию можно считать эдаким компромиссом когда ставится двойной конвейер на одно ядро.

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

Примечательно, что на сайте «Intel» в рекламном ролике показывается скорее двухядерность, нежели «Hyper-Threading», тот кто дочитал до этого момента, наверняка уже догадался почему 🙂

Изображение из видео:

Более точное изображение:

Какой вывод можно здесь сделать и что улучшить?

Вместе с очевидными плюсами, SMT приносит фризы в чувствительные для времени выполнения задачи (воспроизведение видео/музыки или FPS в играх). Именно поэтому, многие геймеры наблюдают падение FPS при включенном SMT/Hyper-Threading. Так как же нам уменьшить эти минусы и не потерять плюсы SMT?

Вот тут как раз нам и поможет управление задачами в ОС.

Как я и написал ранее, мы можем сортировать блоки, выкладываемые на конвейер, ещё на этапе обработки задач ядром ОС. С помощью приоритетов и разделения процессов по ядрам процессора, можно выкладывать определённые блоки на конвейер в нужном количестве и класть разнотипные блоки для разных виртуальных ядер, чтобы не наступало голодание разнотипных задач. Именно для этой задачи динамического анализа в «Windows Performance Station» мы объединили нейросеть и диспетчер задач. В итоге, нейросеть анализирует задачу и раскладывает её в зависимости от полученных данных по разным правилам, благодаря чему, каждое ядро в паре SMT выполняет разные задачи.

Благодаря такому подходу, процессоры с SMT в Windows могут более эффективно работать с многозадачностью и многопоточными процессами. И именно поэтому нас весьма порадовало появление SMT в новых процессорах «AMD Ryzen».

Приложение «Windows Performance Station» бесплатное и не содержит рекламы, его можно скачать с нашего сайта: winperst*ru

Большое спасибо всем, кто осилил данный текст 🙂

Интересно, за что статью заминусовали.

Любимица

Про «разводняк» в интернете

Брешь в системе

Сходство

Каждый раз

Колдовство!

Первый день на работе

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

Несколько смуглых зайцев решили побить контролёра в автобусе, но что то пошло не так

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

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

Спасибо трактористам!

Свое место на парковке

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

Спустя 17 лет

Сын маминой подруги

Источник