Гиперпоточность и турбонаддув в матричном умножении - худшая производительность при использовании гиперпоточности
Я настраиваю свой код GEMM и сравниваю с Eigen и MKL. У меня есть система с четырьмя физическими ядрами. До сих пор я использовал количество потоков по умолчанию из OpenMP (восемь в моей системе). Я предполагал, что это будет по крайней мере так же хорошо, как четыре темы. Однако сегодня я обнаружил, что если я запускаю Eigen и мой собственный код GEMM на большой плотной матрице (1000x1000), я получаю лучшую производительность, используя четыре потока вместо восьми. Эффективность подскочила с 45% до 65%. Я думаю, что это также можно увидеть в этом сюжете https://plafrim.bordeaux.inria.fr/doku.php?id=people:guenneba
Разница довольно существенная. Тем не менее, производительность гораздо менее стабильна. Производительность резко возрастает с каждой итерацией, как с Eigen, так и с моим собственным GEMM-кодом. Я удивлен, что Hyperthreading делает производительность намного хуже. Я думаю, это не вопрос. Это неожиданное наблюдение, на которое я надеюсь найти обратную связь.
Я вижу, что здесь также не рекомендуется использовать гиперпоточность.
Как ускорить матричный продукт Eigen библиотеки?
У меня есть вопрос, касающийся измерения максимальной производительности. Теперь я запускаю CPUz и смотрю на частоту, когда я запускаю свой код GEMM, а затем использую это число в своем коде (4,3 ГГц на одной разогнанной системе, которую я использую). Могу ли я доверять этому номеру для всех тем? Как узнать частоту на поток, чтобы определить максимум? Как мне правильно учесть турбо буст?
3 ответа
Целью гиперпоточности является улучшение использования процессора для кода с высокой задержкой. Гиперпоточность маскирует эту задержку, обрабатывая два потока одновременно, таким образом, имея больше параллелизма на уровне команд.
Однако хорошо написанное ядро матричного продукта демонстрирует превосходный параллелизм на уровне команд и, таким образом, использует почти 100% ресурсов ЦП. Поэтому нет места для второго "гипер" потока, и накладные расходы на его управление могут только снизить общую производительность.
Если я не пропустил что-то, всегда возможно, ваш процессор имеет один такт, который используется всеми его компонентами, поэтому, если вы измеряете его частоту на уровне 4,3 ГГц (или что-то еще), то это частота всех компонентов, для которых имеет смысл вычислить темп. Представьте себе хаос, если бы это было не так: одни ядра работают с одной скоростью, другие - с другой; общие компоненты (например, доступ к памяти) станут неуправляемыми.
Что касается гиперпоточности, фактически ухудшающей производительность умножения вашей матрицы, я не удивлен. В конце концов, гиперпоточность - это техника распараллеливания бедных, дублирующая конвейеры инструкций, но не функциональные блоки. После того, как ваш код начинает кричать n*10^6 Смежные области памяти через FPU, переключение контекста в ответ на остановку конвейера мало чем поможет. В лучшем случае другой конвейер некоторое время будет кричать, пока другой переключатель контекста не отнимет у вас полезные такты, в худшем - все тщательное расположение данных в иерархии памяти будет ужасно искажено при каждом переключении.
Гиперпоточность предназначена не для параллельной числовой скорости вычислений, а для повышения производительности гораздо более общей рабочей нагрузки; Мы используем универсальные ЦП в высокопроизводительных вычислениях не потому, что хотим гиперпоточности, а потому, что все параллельные числовые ЦП специалиста прошли путь всякой плоти.
Как поставщик услуг многопоточного параллелизма, я исследовал, как гиперпоточность влияет на производительность в различных условиях. Я обнаружил, что с программным обеспечением, которое ограничивает свои собственные потоки с высокой загрузкой не более чем фактическими доступными физическими процессорами, наличие или отсутствие HT не имеет большого значения. Программное обеспечение, которое пытается использовать больше потоков, чем это, для тяжелой вычислительной работы, вероятно, не подозревает, что оно делает это, полагаясь только на общее количество процессоров (которое удваивается при HT), и, как и ожидалось, работает медленнее. Возможно, самое большое преимущество, которое может дать включение HT, состоит в том, что вы можете максимально использовать все физические процессоры, не подвергая остальную часть системы обходу. Без HT программное обеспечение часто должно оставлять один свободный процессор для нормальной работы хост-системы. Гиперпотоки - это просто более переключаемые потоки, они не являются дополнительными процессорами.