FP-интенсивная производительность гиперпоточности на последних Xeon

Question

Недавно мы приобрели двойную Intel X5650 рабочую станцию ​​для запуска интенсивного моделирования с плавающей запятой под Ubuntu 10.04.

Каждый X5650 имеет 6 ядер, таким образом, всего 12 ядер. Код тривиально параллелен, поэтому я запускал его в основном с 12 потоками и наблюдал примерно 1200% загрузки процессора через "top".

В BIOS включена поддержка HyperThreading, поэтому операционная система номинально видит 24 доступных ядра. Если я увеличу количество потоков до 24, лучшие сообщат об использовании процессора примерно на 2000% - однако, похоже, что фактическая производительность кода не увеличится на 20/12.

Мой вопрос: как HyperThreading действительно работает с Xeons последнего поколения? Будет ли полезен код с плавающей запятой от планирования более одного потока на ядро? Меняется ли ответ, если рабочий набор имеет порядок размера кэша по сравнению с несколько раз большим, или если имеются существенные операции ввода-вывода (например, запись результатов моделирования на диск)?

Дополнительно - как мне интерпретировать процент использования процессора от "top", когда включена поддержка гиперпоточности?

Answer 1

При использовании HT ОС будет планировать 2 потока для каждого ядра одновременно.Степень использования, сообщаемая top, по сути, является просто средним числом потоков в «рабочем» состоянии за интервал выборки (обычно 1 секунда).Работающие потоки доступны для выполнения ЦП, но, возможно, они не выполняют много работы, например, если они в основном застопорены из-за пропадания кэша.

Когда поток заблокирован в реальной сети ввода-вывода,диск и т. д. - ОС извлечет его из ядра и назначит другой готовый поток, поэтому HT не поможет.

HT пытается получить большее использование от математических исполнительных блоков, фактически не удваивая аппаратное обеспечение в ядре.Если один поток имеет достаточный параллелизм на уровне команд и не сильно пропускает кеш, то он в основном заполнит ресурсы ядра, а HT не поможет.Для тяжелых приложений FP с данными, которые не помещаются в кэш, HT все еще, вероятно, мало поможет, так как оба потока используют одни и те же исполнительные блоки (математика SSE), и оба требуют больше, чем полный кэш - фактически это вероятноранить, так как они будут конкурировать за кеш и побеждать больше.Конечно, это зависит от того, что именно вы делаете и как выглядят ваши шаблоны доступа к данным.

HT в основном помогает в ветвящемся коде с нерегулярными и непредсказуемыми шаблонами доступа.Для FP-интенсивного кода вы часто можете добиться большего успеха с 1 потоком на ядро ​​и тщательным проектированием ваших шаблонов доступа (например, хорошая блокировка данных).

Answer 2

Я разработал очень высокопроизводительный, смущающе параллельный код, который будет работать на максимально возможном количестве ядер.Первоначально он работал на 2-ядерном ноутбуке AMD, но когда я перешел на 2-ядерный ноутбук Intel +, улучшение производительности было незначительным: наличие процессора более позднего поколения, еще двух (HT) ядер и 670 МГц более высокая тактовая частота процессора могли простоне быть замеченнымКогда я ограничил код двумя не-HT потоками, неожиданное ускорение в двухъядерном случае внезапно появилось, и я мог дышать легче.

Когда я изменил уровень оптимизации компилятора с 3 на 2 и, наконец,1 гиперпоточность начала показывать свое обещание.Наилучшие результаты были на уровне оптимизации 1 и были примерно на 50% лучше, чем в случае с двумя кодами без HT.

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

Благодаря менее оптимизированному или плотному коду у потоков была возможность «чередовать» их доступы к ресурсам ядра в большей степени.Это привело к тому, что два потока выполнялись со скоростью около 75% от скорости, с которой наиболее оптимизированный код работал бы на одном ядре.Если подвести итог, то менее оптимизированный код в двух потоках даст в 1,5 раза пропускную способность наиболее оптимизированного в одном.

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