Блог

Главная - Вопросы по программированию - Что вызывает большую разницу в производительности между разными процессорами Zen 1 для простого теста?

Что вызывает большую разницу в производительности между разными процессорами Zen 1 для простого теста?

#performance #caching #cpu-architecture #cpu-cache #amd-processor

#Производительность #кэширование #Архитектура процессора #cpu-cache #amd-процессор

Вопрос:

Я исследую различия в производительности очень простого теста для трех разных процессоров Zen 1, и я наблюдаю огромные различия в командах за цикл и пропуски кэша L2 между Threadripper и процессорами Epyc.

Вопрос

На процессорах Epyc количество команд за цикл (IPC) намного меньше, когда размер рабочего набора больше, чем кэш последнего уровня (LLC).

Почему производительность может так сильно отличаться между процессорами Epyc и Threadripper одного поколения?

Тест

https://github.com/llvm/llvm-test-suite/tree/master/MultiSource/Benchmarks/Olden/treeadd

treeadd Тест в старом наборе. Исходный код доступен как часть набора тестов LLVM.

Бенчмарк рекурсивно создает полное двоичное дерево из 2 ^ N — 1 узлов, где N — входные данные, и выполняет обход 100 раз, выполняя операции только для чтения на каждом узле. Бенчмарк скомпилирован clang с использованием магистрального форка llvm, которому несколько месяцев.

Тест представляет собой однопоточное приложение, работающее на одном ядре.

Тестируемые системы

Система 1

Процессор: Ryzen Threadripper 1950 x (https://en.wikichip.org/wiki/amd/ryzen_threadripper/1950x )
Память: 32 ГБ DDR4 2666
ОС: Ubuntu 20.04, ядро 5.4.0

Система 2

Процессор: Epyc 7601 (https://en.wikichip.org/wiki/amd/epyc/7601 )
Память: 128 ГБ DDR4 2133
ОС: Ubuntu 20.04, ядро 5.8.0

Система 3

Процессор: Epyc 7371 (https://en.wikichip.org/wiki/amd/epyc/7371 )
Память: 128 ГБ DDR4 2133
ОС: Ubuntu 20.04, ядро 5.4.48

Сводная информация о производительности

При запуске теста с N = 22 получается следующая таблица. (Время работы, IPC и ссылки / промахи в кэше):

Время работы, IPC и ссылки на кэш / промахи

Создаются два двоичных файла, один на Threadripper (TR bin), другой на Epyc 7601 (Epyc bin).

Независимо от того, какой двоичный файл используется, IPC Epyc намного ниже, чем у Threadripper. Время работы на стенке указано для справки, но поскольку частоты процессоров разные, их, вероятно, не следует сравнивать напрямую. Использование taskset для привязки теста к одному ядру не приводит к значительному различию чисел.

Судя по всему, разница в IPC вызвана существенными различиями в промахах L2 (событие perf l2_cache_req_stat.ls_rd_blk_c ). Обычным подозрением в этой ситуации является то, что размеры L2 на ядро различны. Однако, согласно документации, все процессоры имеют одинаковый кэш L2 объемом 512 КБ на ядро. Кроме того, я запустил lmbench и получил задержки чтения в трех системах, показанные на этом рисунке ниже.

Задержки чтения кэша

Две диаграммы Threadripper идентичны для удобства сравнения по вертикали и горизонтали. Обратите внимание, что «стена памяти» достигает примерно одинаковых размеров массива, что дополнительно указывает на то, что эти процессоры имеют одинаковые размеры кэшей на ядро. С другой стороны, задержка доступа для разных шагов намекает на возможность того, что Threadripper может иметь необычно эффективную предварительную выборку. Однако отключение предварительной выборки на Threadripper только удваивает частоту пропусков L2 (видно на первом рисунке), и она по-прежнему не приближается к частоте пропусков L2 на машинах Epyc.

Наконец, размер рабочего набора изменяется для проверки влияния размеров кэша. На последнем рисунке показан IPC при изменении размеров рабочего набора. Бенчмарк изменен для выполнения 1000 итераций, чтобы убедиться, что он работает достаточно долго, чтобы получить стабильные цифры.

IPC на трех машинах с разным размером рабочего набора

Хотя на машинах Epyc, похоже, 8 МБ ООО (на CCX из 4 ядер), производительность падает с обрыва, когда размер рабочего набора увеличивается с 3 МБ до 6 МБ.

Различные способы запуска теста

Помимо простого запуска теста, я устал от двух других способов.

  • Используется taskset для привязки бенчмарка к определенному ядру.
  • используется numactl для привязки бенчмарка к определенному ядру и использования membind флага для использования памяти, ближайшей к ядру.

Ни один из них не создал существенно разных профилей.

Догадки

Данные указывают на то, что размеры кэшей на процессорах одинаковы. Следовательно, огромная разница в частоте пропусков L2 может быть связана с разделением кэша на L3. Может быть, Epyc в некоторых ситуациях ограничивает L3 на ядро до 4 МБ?

Краткие сведения

Для одного и того же теста на машинах Threadripper и Epyc наблюдаются значительные различия в IPC. Разница, по-видимому, вызвана необычно высокими пропусками L2 на процессорах Epyc. Однако кэши имеют одинаковые размеры для каждого ядра.

Что могло вызвать значительные различия в промахах L2? Или, может быть, есть что-то еще, вызывающее разницу в IPC?

Комментарии:

1. Все 3 ваших процессора используют один и тот же кэш для компоновки ядра: 4 ядра совместно используют кэш L3 объемом 8 МБ с межсоединениями между этими CCX. Итак, для однопоточных рабочих нагрузок, да, у вас фактически есть кэш объемом 8 МБАЙТ L3. Задержка от L3 до контроллера памяти может варьироваться в зависимости от размера чипа и IDK, если есть какая-либо качественная разница между ThreadRipper и Межсоединение Epyc.

2. Итак, IDK, как ThreadRipper удается поддерживать IPC, когда рабочий набор превышает размер кэша. Возможно, различная предварительная выборка HW позволяет чаще скрывать задержку. Кажется маловероятным, что более быстрая оперативная память может иметь такое огромное значение, но IDK. Зарегистрированные в ECC модули DIMM (серверная память) имеют несколько более высокую задержку, но ваши результаты lmbench, похоже, показывают меньшую задержку DRAM на процессорах Epyc.

3. @PeterCordes IPC на ThreadRipper падает (от 1,8 до 1,6), когда размер рабочего набора превышает размер L3. Это примерно на 10% меньше. Отключение предварительной выборки путем изменения MSR оказывает значительное влияние на TR (IPC с 1.6 до 1), когда размер рабочего набора равен 96, но это все равно не так плохо, как у Epycs с включенной предварительной выборкой. Результаты lmbench намекают на возможность того, что TR имеет хорошую предварительную выборку, когда шаги невелики, что, вероятно, и является нашим случаем здесь. Размер узла дерева составляет 24 байта. Но я думал, что это процессор одного поколения, и они, вероятно, имеют одинаковый uarch.