Есть ли у Hyperthreading проблемы с AVX?
Играя с разгоном и запуском тестов прожига, я заметил, что оптимизированная AVX версия LINPACK измеряла более низкую многопоточную пропускную способность с плавающей запятой при включенном Hyperthreading, чем при отключенном. Это было на Ivy Bridge i7 (3770k). Я также заметил, что при отключенном Hyperthreading LINPACK приводил к более высокой температуре ядра, несмотря на то, что процессор работал на более низком напряжении ядра. Все это заставляет меня поверить, что без Hyperthreading использование конвейера на самом деле выше.
Мне любопытно: является ли это просто чем-то присущим алгоритму LINPACK, который вызывает остановку конвейера или неэффективное распределение с помощью SMT, или у реализации Intel SMT законно возникают проблемы с планированием конвейеров, когда оба потока выдают широкие инструкции SIMD? Если так, то это что-то, что Haswell решил, или это будет решаться в будущих архитектурах Intel? Это проблема AVX512 склонна иметь?
Наконец, есть ли какие-то хорошие шаги, которые можно предпринять при программировании с использованием AVX для систем Intel, чтобы избежать неэффективного распределения конвейера с помощью SMT?
1 ответ
Гиперпоточность распределяет ресурсы не по порядку выполнения между двумя аппаратными потоками, вместо того, чтобы передавать их всем одному потоку. Обычно вы ожидаете, что в худшем случае не увидите ускорения, если один поток уже может поддерживать конвейер заполненным. В любом случае, исполнительные единицы должны жевать 4 мопа / часы инструкций, которые должны быть выполнены.
Если каждый поток работает на своем собственном куске памяти, ядра ЦП затем пытаются одновременно манипулировать большим количеством активных данных. Конкурентное совместное использование кэшей L1 / L2 означает, что это может оказаться хуже, чем без HT.
Кроме того, для некоторых рабочих нагрузок требуется параллелизация. Только смущающие параллельные задачи (например, выполнение множества независимых матемул, а не распараллеливание одной большой) имеют незначительные накладные расходы для координации потоков.
Как упоминает Агнер Фог в своем руководстве по Оптимизирующей сборке, если какой-либо из ресурсов ЦП с конкурентным разделением или разделением ресурсов является узким местом, гиперпоточность не поможет, а может повредить. Прекрасно, когда код тратит много времени на ошибочные прогнозы веток или кеш, поскольку другой поток может не дать голодному конвейеру бездействовать.
Матрица математики имеет достаточно предсказуемые шаблоны доступа, поэтому кеширование и промахи происходят редко. (особенно в коде, который тщательно заблокирован для размеров кэша.)
Как избежать того, чтобы HT не помог: сделайте ваш код медленным, чтобы один поток не мог выполнить его достаточно эффективно, чтобы поддерживать конвейер заполненным. >.<. Если серьезно, если есть алгоритм с отсутствием кэша или ошибочным прогнозом ветвления, который работает одинаково по сравнению с методом грубой силы, его использование может помочь. Например, тесты для ранних выходов могут быть почти бесполезными, учитывая непредвиденные издержки ветвления в одном потоке, но могут быть намного быстрее, когда ваш код выполняется на двух потоках HW одного и того же ядра, поэтому метод грубой силы находится на недостаток.