Гиперпоточность и какая польза от приложений

373
Erik9631

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

Я был в порядке с ответом, пока не столкнулся с сеттингом в одной игре, что полностью меня оттолкнуло. Есть игра под названием Arma 3, в настройках которой есть настройка «Hyper Threading». Я потрудился немного погуглить и наткнулся на пост от разработчика, который объясняет, что делает настройка. Он сказал именно это

то, что он делает - говорит движку использовать ядра HT только для потоков с небольшими задачами / микро-заданиями ... просто помните, что -cpuCount = отменяет -enableHT

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

Может ли кто-нибудь прояснить это для меня? Потому что это честно сбивает с толку. Благодарю.

0

1 ответ на вопрос

0
Austin Hemmelgarn

Чтобы объяснить причину, по которой Hyper Threading помогает, требуется некоторое объяснение того, что это такое, и, в свою очередь, как ресурсы распределяются в процессоре.

Фон

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

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

Вероятно, стоит отметить, что Hyper Threading - это не то же самое, что Symmetric MultiThreading, предоставляемый некоторыми другими архитектурами ЦП (POWER, SPARC и (возможно) чипами AMD Ryzen). SMT намного ближе к классическому многоядерному дизайну и не страдает от большинства проблем, которые делает Hyper Threading.

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

Ну, на самом деле это сложно сказать. Чтобы получить максимально возможную выгоду, вам на самом деле нужно сгруппировать подобный код в пары потоков, которые совместно используют ресурсы внутри ЦП), но даже в этом случае трудно быть уверенным, действительно ли Hyper Threading сильно поможет. Некоторые старые операционные системы вообще не делали такого типа группировки, и результаты по-прежнему считаются ярким примером фразы «патологически плохой». Более новые системы делают некоторый уровень группировки, но это все еще не идеально.

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

Однако достаточно хорошо известно, какие типы рабочих нагрузок хуже работают с SMT. Практически все, что требует использования всех ядер ЦП при 100% нагрузке, вряд ли получит большую пользу от SMT. На чипах HT он иногда будет работать медленнее, чем при отключенном HT. В некоторых других реализациях это может улучшать или не улучшать вещи или ухудшать их, в зависимости от того, что делается (например, микросхемы SPARC хорошо справляются с такими рабочими нагрузками, если они не выполняют действительно глубоко вложенные вызовы функций).

Хорошо, так что с этим Arma 3?

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

Можете ли вы указать, что вы подразумеваете под «Группировка кода». Я гуглял по каналам C ++ (так как я являюсь разработчиком C ++), и из того, что я прочитал, нет никакого способа программно использовать гиперпоточность. Все, что вам нужно сделать, это запустить поток и позволить ОС справиться с этим. Вы можете это уточнить? Erik9631 6 лет назад 0
@ Erik9631 Нет способа программно использовать HyperThreading напрямую. Однако вы можете указать планировщику, на какое логическое ядро ​​поместить каждый из ваших потоков и процессов, что позволит вам контролировать, в каком потоке и на каком физическом ядре они запускаются. Системный вызов для этого в Linux называется `sched_setaffinity`, я не совсем уверен, что такое эквивалент Windows, но я знаю, что он существует. В большинстве систем два потока сгруппированы в логическом порядке ядра (поэтому 0 и 1 - это одно физическое ядро, 2 и 3 - следующее, и т. Д.), Поэтому выяснить расположение не сложно. Austin Hemmelgarn 6 лет назад 0

Похожие вопросы