hyperthreading и turbo boost в матричном умножении - худшая производительность с использованием гиперпотока

Question

Я настраиваю свой код GEMM и сравниваю его с Eigen и MKL. У меня есть система с четырьмя физическими ядрами. До сих пор я использовал количество потоков по умолчанию из OpenMP (восемь в моей системе). Я предположил, что это будет по крайней мере так же хорошо, как четыре потока. Однако сегодня я обнаружил, что, если я запускаю Eigen и свой собственный код GEMM на большой плотной матрице (1000x1000), я получаю лучшую производительность с использованием четырех потоков вместо восьми. Эффективность подскочила с 45% до 65%. Я думаю, что это также можно увидеть на этом графике https://plafrim.bordeaux.inria.fr/doku.php?id=people:guenneba

Разница довольно существенная. Однако производительность намного менее стабильна. Производительность скачков вокруг немного выше каждой итерации как с Eigen, так и с моим собственным кодом GEMM. Я удивлен, что Hyperthreading делает работу намного хуже. Наверное, это не вопрос. Это неожиданное замечание, на которое я надеюсь найти отзывы.

Я вижу, что здесь не рекомендуется использовать гиперпотоки.
How to speed up Eigen library's matrix product?

У меня есть вопрос относительно измерения максимальной производительности. Теперь я запускаю CPUz и смотрю на частоту, когда я запускаю свой код GEMM, а затем использую этот номер в своем коде (4.3 ГГц на одной разогнанной системе, которую я использую). Могу ли я доверять этому номеру для всех потоков? Как узнать частоту на поток для определения максимума? Как правильно объяснить турбобус?

Answer 1

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

Однако хорошо написанное матричное ядро ​​продукта демонстрирует превосходный параллелизм на уровне инструкций и, таким образом, использует почти 100% ресурсов процессора. Поэтому нет места для второй «гипер» нити, и накладные расходы на ее управление могут только снизить общую производительность.

Answer 2

Если я пропустил что-то, всегда возможно, ваш процессор имеет один такт, разделяемый всеми его компонентами, поэтому, если вы измеряете его скорость на 4.3 ГГц (или что-то еще), то это скорость всех компонентов, для которых это имеет смысл чтобы определить курс. Представьте себе хаос, если это не так, некоторые ядра работают с одной скоростью, другие - с другой скоростью; общие компоненты (например, доступ к памяти) станут неуправляемыми.

Что касается гиперпотока, фактически ухудшающего производительность умножения матрицы, я не удивлен. В конце концов, гиперпоточность - это метод параллелизма у плохого человека, дублирующий конвейеры команд, но не функциональные единицы. После того, как вы получите крик вашего кода, нажимая ваши смежные области памяти n*10^6 через FPU, контекстный переключатель в ответ на стойку конвейера не поможет. В лучшем случае другой конвейер будет кричать на некоторое время, прежде чем другой коммутатор контекста выбьет вам полезные тактовые циклы, в худшем случае все тщательное расположение данных в иерархии памяти будет ужасно искажено на каждом коммутаторе.

Hyperthreading предназначен не для параллельной вычислительной скорости, а для повышения производительности гораздо более общей рабочей нагрузки; мы используем процессоры общего назначения в высокопроизводительных вычислениях не потому, что хотим получать гиперпотоки, а потому, что все специализированные параллельные числовые процессоры пошли по пути всей плоти.

Answer 3

Как поставщик многопоточных служб параллелизма, я изучил, как гиперпоточность влияет на производительность при различных условиях. Я обнаружил, что с программным обеспечением, которое ограничивает свои собственные потоки с высоким уровнем использования, не более того, что доступные физические процессоры доступны, наличие или отсутствие HT делает очень мало различий.Программное обеспечение, которое пытается использовать больше потоков, чем для тяжелой вычислительной работы, скорее всего, не знает, что это так, опираясь только на общий счет процессора (который удваивается под HT) и, как ожидается, работает медленнее. Возможно, самое большое преимущество, которое может обеспечить HT, заключается в том, что вы можете максимизировать все физические процессоры, не доведя остальную часть системы до обхода. Без HT программное обеспечение часто должно оставить один процессор свободным, чтобы хост-система работала нормально. Hyperthreads - это всего лишь переключаемые потоки, они не являются дополнительными процессорами.