Comments 19
Так, например, компания Intel в своей документации к библиотеке MKL рекомендует производить вычисления только на производительных ядрах.
Точно рекомендует? а то ведь там написано
This approach might not yield the best performance
И по факту MKL по дефолту грузит все ядра.
Буквально в этом же абзаце
Therefore, for hybrid architectures like Alder Lake, we recommend running threads on the P-cores only.
Я не знаю, что это, если не рекомендация :)
А то, что по дефолту грузит все ядра - в этом как раз и есть главная проблема, которая и побудила меня на статью. Поведение по умолчанию может сильно проигрывать. По ссылке Intel как раз рекомендует менять значение переменно окружения KMP_HW_SUBSET, чтобы явно указывать, где исполнять вычисления.
И кстати, неплохо бы было сравнить скорость вашего кода с реализацией из того же MKL
E-ядра в параллельных вычислениях - полная лажа. Я пробовал openFoam гонять с разными конфигами на 12900К - Любое добавление E-ядер уменьшало производительность. Может конечно Intel MPI не умел на тот момент учитывать производительность разных ядер, но результаты бенча были такими:
Тут скорее вопрос к реализации openFOAM — есть ли там балансировка? MPI — же просто интерфейс обмена сообщениями, если декомпозиция задачи была выполнена без учета дисбаланса, то уже реализация MPI не поможет.
MPI он ничего не балансирует, как отдекомпозишь модельку - так и поедешь.
Вообще OpenFOAM он про доступ в память больше, а не про флопсы. Большой кэш, больше каналов, более быстрая память - вот что ему нужно.
Ну или если только эта моделька не размера микро, что целиком в L3 помещается, тогда да, ядра могут что то сказать, но не ранее.
Непонятен один совсем простенький момент. Сколько ядер использовалось? Всего. В штуках?
Теория такая: если у вас есть супер производительные штуки, то даже если конкуренты в тысячу раз медленнее, но их тысячи, то они суммарно всё же выиграют. В вашем случае конкурентов 16, а супергероев 8. Так для кого построены графики? Для 8 против 16, или 8 против 24, или 8 против 8? Или?
Удивлён, что очевидные характеристики теста отсутствуют.
Ну и про память. Если даже для 8 участников всё упирается в её пропускную способность, то все остальные тесты есть вообще полная профанация. Вы как-нибудь измеряли вклад памяти? Или опять придётся удивляться?
При прочих равных эксперимент должен выглядеть как 8 быстрых против 8 медленных. Но на это, как уже было замечено, при проведении тестов внимание обращено не было. Ну или не указано в тексте, хотя и очевидно важно.
Смотрите, нет вопроса "8 производительных или 8 энергоэффективных?". Энергоэффективные ядра все-таки слишком слабы (в этой задаче 1 к 4 примерно).
Вопрос ставится следующим образом: только производительные или производительные совместно с энергоэффективными? Характеристики стенда я указал — то есть тесты приведены для 8P против 8P+16E. Будет какой‑то другой процессор с двумя P‑ядрами и 128 E‑ядрами — картина будет конечно другая, но софт делается здесь и сейчас под существующие процессоры.
Про память - из графиков видно, что упор в память происходит только начиная с определенного размера задачи, так что я не знаю, чему здесь можно удивляться.
Будет какой‑то другой процессор с двумя P‑ядрами и 128 E‑ядрами — картина будет конечно другая, но софт делается здесь и сейчас под существующие процессоры.
Ну так есть SierraForest , где в топе 144 Е-ядер на сокет. В обычных числодробительных задачах это конечно унылое зрелище, но есть задачки в которых может и потащить.
В тестах аналога, но на поколение моложе, ситуация такая:
На обычных командах (без AVX2) имеем на медленное ядро производительность ~85-86% от быстрого, то есть ровно на разницу в частотах ядер. На AVX2 имеем ~47-48% от быстрого ядра, с учётом частоты будет ~53%. То есть ваши замеры, очевидно, что-то не учли. Скорее всего кэш. Ну и многое другое, предполагаю, тоже.
Давно говорено, что для получения точной статистики необходимо много думать о том, что измеряется. Если эксперимент поставлен внешне логично, но не учёл хотя бы одну важную деталь, вы получаете то, что получили. Но предложенная методика тестирования не учитывает больше чем одну важную деталь.
Я правильно понимаю, что суть вашей претензии сводится к тому, что "о, ужас" все программы разные? Одни compute bound, другие memory?
Скорее всего кэш.
Допустим, но вывод то какой? Не писать программы, которые активно используют кэш? Не запускать их?
Вывод такой: необходимо разграничивать условия, в которых софт даёт нужные результаты. Нормальное исследование предполагает выявление свойств изучаемого объекта в достаточном многообразии вариантов применения, что бы такими результатами можно было воспользоваться в неких реально полезных областях применения. Если же области применения не учитываются, то практическая польза от исследования остаётся околонулевой.
В вашем случае стоит повторить работу с учётом хотя бы уже перечисленного, то есть, во первых, изолировать собственно вычислительный аспект, не давая сторонним эффектам вроде кэша и скорости доступа к памяти помешать, и во вторых, добавить трансграничных данных, то есть показать, как система ухудшает/улучшает поведение при переходе через чётко обозначенные границы. Ну а границы вам ещё предстоит выяснить.
Кстати, compute bound и memory bound - далеко не полный набор ограничений, которые стоит учитывать.
Поэтому не надо про "не писать программы", надо про "исправить".
Ни в коем случае не претендую данной статьей на анализ многообразия вариантов применения. Но тем не менее считаю, что выбранная задача похожа на типичную нагрузку в задачах моделирования и обработки данных, где OpenMP как раз широко и используется. С этой же точки зрения считаю, что любая изоляция вычислительного аспекта только бы снизила практическую пользу от исследования.
Но в целом я вас понял. Буду только "За", если вы выполните собственное исследования, исходя уже из типичной нагрузки в вашей области. На этом же предлагаю закончить дискуссию.
Для обучения детей такому, неплохо бы добавить анролов циклов либо симд инструкции, у Вас не зря производительность выше теор оценки, но в то же время, она отстает от симд оценок как минимум в 4 раза. Интересно как при использовании векторизации Ваши наблюдения изменятся
Есть ли толк от E-ядер в OpenMP приложениях?