Влияние реплея на Hyper-Threading
Основная цель технологии Hyper-Threading – повысить КПД использования вычислительных ресурсов за счёт того, что два потока не имеют зависимости по данным, и один из потоков может использовать те вычислительные ресурсы, которые не использует другой, особенно в моменты, когда один из потоков простаивает. Обычно в процессорах ожидание данных из RAM вызывает длительные простои вычислительных ресурсов. Самое время эти ресурсы использовать потоком, не ожидающим данных из RAM.
Но что будет с производительностью, когда вмешивается реплей?
Как уже было описано выше, "зацикливание" цепочки команд в системе реплея на долгое время может приводить к большому и совершенно неэффективному потреблению ресурсов. Например, в случае отсутствия данных в кэшах первого и второго уровней цепочка команд будет вынуждена совершить десятки, а то и сотни оборотов в системе реплея, бесцельно занимая вычислительные устройства в ожидании прибытия данных из основной памяти. Если NetBurst-процессор однопоточный, то ожидание данных из памяти в системе реплея не создаёт больших дополнительных проблем производительности, так как процессор в любом случае теряет сотни тактов в ожидании данных из оперативной памяти (вычислительный поток всё равно надолго приостанавливается в ожидании данных). Дополнительная работа узлов процессора сказывается в этих случаях больше на тепловыделении.
Но когда на процессоре одновременно исполняются два потока, неэффективное потребление ресурсов многократным реплеем одного из потоков просто не может не сказываться на производительности другого. Можно предположить, что, чем чаще поток обращается к данным, отсутствующим в кэшах первого и второго уровней, тем больше ресурсов он потребит из-за реплея в ожидании данных.
Мы решили проверить теорию на практике. Для этого была написана программа, один поток которой имеет длинную цепочку зависимости по данным и для вычислений постоянно обращается к данным в памяти по случайным адресам, а другой поток просто проводит вычисления на регистрах, почти не обращаясь к памяти. Оба потока исполняют команды одного типа (AND) на одном и том же FastALU0. Целью эксперимента была проверка того, как изменяется производительность второго потока, не обращающегося к памяти, в зависимости от того, обращается первый поток к данным в кэше первого уровня, второго уровня или оперативной памяти. Результаты тестирования процессора Pentium 4 Northwood приведены на рис. 10.
Рис. 10. Тестирование влияния реплея на
Hyper-Threading (процессор Northwood)
На рис. 10 отображена зависимость производительности второго вычислительного потока (Поток2) от размера буфера данных первого потока (Поток1), обращающегося к данным по псевдослучайным адресам.
Результаты говорят сами за себя. Ожидание данных из памяти одним потоком приводит к ощутимому замедлению скорости исполнения второго потока (> 35% по сравнению с ожиданием данных из L1). Поток, ожидающий данные из оперативной памяти, вместо того чтобы освободить ресурсы на время простоя, занимает их больше (!), чем во время нормального исполнения, когда данные находятся в L1. Ситуацию при HT усугубляет тот факт, что два потока разделяют объём L1 и L2 между собой, а значит эффективный объём кэш-памяти, приходящийся на каждый поток, сокращается вдвое. Это в свою очередь означает, что увеличивается число кэш-промахов и, как следствие, реплей-случаев, а значит снижается производительность обоих потоков. Именно реплей может быть одной из причин того, почему включение HT на некоторых задачах приносит вред вместо пользы.
Разобравшись с результатами, показанными процессором Pentium 4 с ядром Northwood, мы решили протестировать процессор с новым ядром Prescott, тем более, что компания Intel заявляла об усовершенствовании технологии Hyper-Threading в этих процессорах. Получив результаты тестирования, отображающие влияние количества кэш-промахов (а значит и реплея) одного потока на производительность другого потока, мы не остались разочарованными.
Рис. 11. Тестирование влияния реплея
на Hyper-Threading (процессор Prescott)
Влияние реплея на производительность не просто уменьшилось, оно стало существенно другим. Во-первых, производительность потока теперь всегда выше, если технология HT включена. Во-вторых, в случаях отсутствия данных в кэшах первого и второго уровней производительность второго потока оказывается несколько выше, чем в случае, если данные есть в кэше второго уровня.
Так разрыв был бы больше.
Ответить с цитированием
Сообщение от FilippOk
