Интенсивное FP выполнение гиперпоточности на последних Xeon
Мы недавно купили двойную рабочую станцию Intel X5650 для выполнения интенсивного моделирования с плавающей точкой, в соответствии с Ubuntu 10.04.
Каждый X5650 имеет 6 ядер, таким образом, существует 12 ядер всего. Код тривиально параллелен, таким образом, я выполнял его главным образом с 12 потоками и наблюдал приблизительно "1 200%-ю" загрузку процессора через "вершину".
HyperThreading включают в BIOS, таким образом, операционная система номинально видит 24 доступные ядра. Если я увеличиваю число потоков к 24, вершина сообщает о приблизительно 2 000%-й загрузке процессора - однако, не кажется, что фактическая производительность кода увеличивается на 20/12.
Мой вопрос - как HyperThreading на самом деле работает над последним поколением Xeon? Интенсивный код с плавающей точкой извлек бы выгоду из планирования больше чем одного потока на ядро? Ответ изменяется, если рабочий набор находится на порядке размера кэша, по сравнению с несколько раз большим, или если существуют существенные операции ввода-вывода (например, запись выводов моделирования к диску)?
Дополнительно - как я должен интерпретировать проценты загрузки процессора от "вершины", когда гиперпоточность включена?
1 ответ
С HT, ОС будет планировать 2 потока на каждое ядро одновременно. Использование, о котором сообщает top, по сути, является средним числом потоков в состоянии "работает" за интервал выборки (обычно 1 секунда). Работающие потоки доступны процессору для выполнения, но они могут не выполнять много работы, например, если они в основном застопорились из-за пропусков кэша.
Когда поток блокируется на реальном вводе/выводе - сетевом, дисковом и т.д. -- ОС снимет его с ядра и назначит другой готовый поток, так что HT не поможет.
HT пытается получить больше пользы от блоков математического исполнения без реального удвоения аппаратного обеспечения в ядре. Если один поток обладает достаточным параллелизмом на уровне инструкций и не пропускает много кэша, то он будет в основном заполнять ресурсы ядра, и HT не поможет. Для тяжелых FP-приложений с данными, которые не помещаются в кэш, HT, вероятно, не поможет, поскольку оба потока используют одни и те же единицы исполнения (SSE-математика), и обоим требуется больше, чем полный кэш - на самом деле, это, скорее всего, навредит, поскольку они будут конкурировать за кэш и больше "трэшить". Конечно, это зависит от того, что именно вы делаете и как выглядят ваши модели доступа к данным.
HT в основном помогает в ветвистом коде с нерегулярным и непредсказуемым доступом. Для FP-интенсивного кода вы часто можете добиться большего, используя 1 поток на ядро и тщательное проектирование паттернов доступа (например, хорошая блокировка данных).