Тестирование влияния кэша L4 процессора i7-5775C на производительность сервера Minecraft: Java Edition

Глава 0. Введение

Приветствую, энтузиаст! Давайте разберем, каким образом почтенный процессор Broadwell из далекого 2015 года выжимает максимум из собственной подсистемы памяти (напомню, речь идет об архитектуре LGA1150 в паре с DDR3), практически догоняя по показателям задержек современные аналоги.

Глава 1. Что такое L4 и с чем его едят?

Может показаться, что здесь кроется несостыковка: как чип с оперативкой родом из школьной поры умудряется тягаться со статными представителями семейства Skylake вроде i7-6700K?

Весь секрет таится в архитектуре подсистемы памяти, а именно — в наличии кэша четвертого уровня (L4), он же eDRAM.

Технология eDRAM (embedded Dynamic Random Access Memory) изначально задумывалась как высокоскоростной буфер, призванный расширить пропускную способность памяти для интегрированной графики Iris Pro 6200.

И все же, раз этот буфер создавался для встройки, почему на схеме он не только интегрирован в кольцевую шину, но еще и пожертвовал частью тегов L3-кэша? Все предельно просто: в ту эпоху корпорация Intel практически не встречала сопротивления на рынке (линейка AMD Bulldozer находилась в глубоком кризисе), поэтому инженеры могли позволить себе подобные вольности. К тому же, в дальнейшем станет очевиден смысл этого эксперимента. Но не будем забегать вперед.

Теги L4-кэша, занявшие часть транзисторного ресурса трехуровневого кэша, развязали руки префетчеру, позволив ему действовать гораздо агрессивнее. За счет чего это работает? Ядра получают страховочную подушку, которая нивелирует негативный эффект от засорения кэша L3. Безусловно, это привело к уменьшению объема кэша на ядро с привычных для той поры 2 МБ до 1.5 МБ (суммарно 6 мегабайт на весь кристал), однако взамен процессор взаимодействует не с медленной DDR3 с задержкой около 65 нс, а с eDRAM, где латентность составляет порядка 45 нс.

Сам по себе кэш L4 функционирует по принципу Non-Inclusive Victim Cache (неинклюзивный кэш жертв). Иерархия обработки данных выстроена следующим образом:

1. Сперва процессор обращается к системной памяти и подтягивает информацию в кэш L3.

2. Столкнувшись с критической ситуацией, когда новоприбывшие сведения вызывают загрязнение кэша (Cache Pollution) и требуют немедленного перемещения,

3. процессор вынужден либо сбрасывать их обратно в ОЗУ, либо искать альтернативу.

4. И здесь начинается самое интересное! Если стандартному процессору (например, Haswell) приходится отправлять мусор обратно в оперативку, то наш экспериментальный Broadwell действует изящнее, перенаправляя эти блоки в eDRAM.

5. Если же впоследствии процессору вновь понадобятся данные, которые сначала посчитали балластом, ему не придется обращаться к медленной DDR3 и провоцировать простои. Вместо этого, задействуя теги L4 внутри L3, он мгновенно забирает информацию из кэша четвертого уровня через системный агент.

Другими словами, перед нами вместительное хранилище для всего того, что не поместилось в L3, но выбрасывать в оперативку процессор категорически не хочет. Настоящий цифровой Плюшкин.

А как на это смотрит операционная система? А абсолютно никак 🙂 Дело в том, что для ядра ОС и регистраторов MSR, отслеживающих нагрузку, кэш L4 остается абсолютно невидимым. Совсем. В диагностических утилитах вроде intel-pcm или perf вы не обнаружите счетчиков вроде L4MISS или L4HIT. Любые операции за пределами трехуровневого кэша никак не фиксируются штатным мониторингом. Именно поэтому единственным способом оценить активность eDRAM (который мы здесь и применим) является анализ пропускной способности DDR3 и показателя IPC.

Глава 2. Работа JVM на сервере Minecraft и префетчер — вещи несовместимые

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

Мало того, что это существенно увеличивает рабочее пространство процессора, так еще и предъявляет жесточайшие требования к задержкам памяти. Центральному процессору жизненно необходимо обрабатывать эти разрозненные структуры с минимальными задержками. В противном случае неизбежны постоянные простои в ожидании порции данных, что неминуемо ведет к просадке IPC (количества выполняемых за такт инструкций).

Рассмотрим классический пример: цепочки указателей (Pointer chasing) в наиболее экстремальном сценарии. Допустим, мы устраиваем масштабный взрыв колоссального количества блоков динамита прямо в игре. В момент детонации происходит следующая цепная реакция:

1. Ядро CPU запрашивает параметры первой сущности TNT.

2. Проверяется иерархия кэшей — фиксируется промах.

3. Процессор отправляет запрос в оперативную память.

4. Ожидая ответа, исполнительный блок фактически простаивает: стандартный префетчер бессилен предсказать столь хаотичный скачок по памяти.

5. Наконец, данные получены! Точнее, не совсем данные, а очередной указатель на следующий взорванный блок TNT, после чего вся процедура запускается по новой.

Вот тут-то наш процессор-Плюшкин и раскрывает свой потенциал. В то время как префетчеры обычных Haswell или Skylake вынуждены действовать предельно осторожно, опасаясь замусорить кэш L3 (ведь угадать траекторию потока невозможно), Broadwell способен принимать лавины таких запросов. Да, с одной стороны, он чаще будет сталкиваться с промахами L3 из-за меньшего объема и активнее взаимодействовать с ОЗУ. Но у него есть куда сбрасывать избыточную информацию! В итоге при колоссальных нагрузках, когда процессору приходится разгребать гигантские массивы указателей, технология eDRAM спасает положение, стабилизируя показатель IPC и снижая нагрузку на системную память.

Часть 3. Тестовое оборудование

В качестве подопытных образцов были отобраны максимально близкие по духу процессоры: Intel Core i7-5775C (о чем недвусмысленно намекало название материала) и Xeon E3-1230V3. Пробежимся по их характеристикам:

1. Максимальная частота в режиме Turbo Boost на одно ядро: 3.7 ГГц.

2. Конфигурация ядер и потоков: 4 / 8.

3. Оба кристалла подверглись процедуре скальпирования с заменой термоинтерфейса на жидкий металл и последующей обратной склейкой.

4. Перед нами представители микроархитектур Broadwell и Haswell соответственно. Разница в базовом IPC составляет около 3–5% в пользу i7-5775C за счет небольших архитектурных оптимизаций, при условии полной загруженности вычислительных блоков.

Кто-то может заметить: автор, у них же отличаются спецификации частоты при полной нагрузке на все ядра (All-Core Turbo)! Верно, отличаются, но об этом чуть позже.

Абсолютная конфигурация тестового стенда:

Материнская плата: Asus H97-PLUS.

1. Оперативная память: 16 ГБ DDR3 (комплект из 4 планок Elixir емкостью по 4 ГБ на чипах Nanya) с профилем XMP 9-9-9-28 2T на частоте 1600 МГц.

2. Накопитель Intel Optane M10 на 16 ГБ под директорию игрового сервера.

3. Системный SSD Hynix PC401 объемом 256 ГБ.

4. Система охлаждения: кулер Deepcool боксового типа с медным сердечником.

5. Дискретная видеокарта NVIDIA GT 710 (установлена исключительно для исключения влияния встроенного графического ядра).

Теперь самое главное: программное обеспечение и методика фиксации одинаковых частот по всем ядрам. Фиксируем параметры:

1. Операционная система: Debian GNU/Linux 13 (Trixie).

2. Регулятор частоты (Governor) переведен в профиль Performance (что принудительно заставило процессоры удерживать пиковые частоты).

3. Среда выполнения: OpenJDK 25 jre-headless.

4. Игровой сервер: PurpurMC сборки 26.2, билд № 112.

5. Сбор метрик производился с помощью утилиты intel-pcm.

Аргументы запуска виртуальной машины Java: java -Xms8G -Xmx8G -XX:+UnlockExperimentalVMOptions -XX:+AlwaysPreTouch -XX:+UseG1GC -XX:G1NewSizePercent=35 -XX:G1MaxNewSizePercent=60 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=16M -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 -jar server.jar nogui

Переходим к практическим испытаниям!

Глава 4. И чем же ты хочешь нас удивить?

Было проведено два сценария тестирования, создающих принципиально разную нагрузку на процессоры:

1. Предварительная генерация мира с использованием плагина Chunky в радиусе 2000 блоков.

2. Масштабный подрыв сферы из динамита радиусом 30 блоков (что эквивалентно примерно 113 000 блоков) в идентичных координатах, с тем же сидом генерации и типом ландшафта.

Зерно мира (Seed): 42157344778486, тип мира: AMPLIFIED, центральные координаты взрыва: -86.300 / 270 / -18.492

Внутриигровые показатели вроде TPS или MSPT не фиксировались: нагрузки заведомо экстремальные, в таких условиях никто не играет. Перед нами чистокровный бенчмарк для JVM-окружения. Куда интереснее проанализировать поведение подсистемы памяти и самих процессоров. В фокусе внимания оказались: IPC, количество промахов трехуровневого кэша и объем трафика DDR3.

Что демонстрируют графики? Ровно то, о чем говорила теория!

Анализируем первый этап: прегенерация мира — процесс относительно предсказуемый и линейный. Полезная работа (IPC) обоих процессоров стабильно держится выше отметки 2, а интенсивность обращений к ОЗУ и промахи L3 коррелируют между собой. Префетчеры успешно справляются с задачей, а сама процедура завершилась за сопоставимое время с теми самыми 3–5% разницы.

Переходим к этапу номер два: момент детонации. Обратите внимание на график промахов кэша у i7-5775C. Их действительно много. Трафик памяти у этого же чипа образует отчетливый «горб». Но ключевой показатель — IPC. У модели i7-5775C этот параметр выше и стабильнее. Пока процессор Xeon E3-1230V3 задумчиво ожидает новые порции инструкций, Broadwell обрабатывает потоки информации бодрее и принимает решения значительно быстрее.

Но как такое возможно, если количество промахов кэша у Broadwell объективно выше?

Весь фокус кроется в уже упомянутом eDRAM. Считавшиеся «мусорными» данные на деле оказываются востребованными, а путь за ними предельно короткий — достаточно заглянуть в собственную кладовую, а не отправляться за информацией в системную память. Иными словами, Broadwell успешно нивелирует задержки ОЗУ за счет использования фирменного кэша L4.

Ниже приведены индивидуальные графики для каждого из тестируемых процессоров:

Глава 5. Итоги

Очевидно, что для ресурсоемких серверных задач под управлением Java критически важно снижать латентность подсистемы памяти! Собственно, именно поэтому сегодня столь популярны процессоры AMD с технологией 3D V-Cache, позволяющие локализовать массивы критически важных данных прямо на кристалле. Объем кэша L3 не бесконечен, и когда количество игровых объектов в памяти JVM исчисляется тысячами, стандартных буферов уже недостаточно.

Резюмируя сказанное: если планируется запуск небольшого локального сервера на стандартном ядре для узкого круга игроков, имеет смысл присмотреться к решениям Ryzen с 3D V-Cache. Если же речь идет о проектах с колоссальным скоплением сущностей, бороться за снижение задержек оперативной памяти придется всеми доступными методами.

Исходные материалы статьи доступны на Яндекс.Диске: https://disk.yandex.ru/d/x9_FIr3ik7W1Vw

 

Источник