Серверные процессоры AMD EPYC Rome 7x32 — рекордная производительность на одно ядро

[leechong]

К последнему абзацу подходит:
«Что этот красный себе позволяет!?»

[Fitrager]

Мой университет заказал три AMD Epyc 7742. Жду с нетерпением когда они придут, чтобы протестировать их. Жаль, что они на 14 нм. Intel, к сожалению, ничего подобное предложить не может. Раньше только Intel брали, но сейчас AMD просто безальтернативный вариант по цене — производительности.

[Mad__Max]

Кто «они» на 14нм?

Вроде речь Epyc 7742, а они по технологии 7нм (ядра и кэш) + 12нм (контроллеры памяти и I/O) делаются.
Причем тут 14нм тогда?

P.S.
Как впечатления от тестирования и эксплуатации в итоге?

[Fitrager]

Кто «они» на 14нм? — странно, смотрел характеристики и там было 14 нм и я еще удивился, что десктопные процессоры уже на 7 нм. Опечатка была на сайте видимо.

Положительные впечатления. Процессор умеет динамически распределять нагрузку по ядрами — наши старые intel так не умели. Плюс смогли запустить распознавание лиц исключительно на эти процессорах без видеокарты — получили неплохой fps. На Intel пару кадром показывало. Теперь только AMD Epyc будем брать.

[edo1h]

Процессор умеет динамически распределять нагрузку по ядрами — наши старые intel так не умели.

ничего не понял, можете пояснить?

[Fitrager]

То ПО, что использовали грузило выборочно ядра на 100%. Новые процессоры сами равномерно распределяли нагрузку на ядра, т.е. загружены были все ядра, но равномерно и пропорционально нагрузке.

[edo1h]

разве этим не планировщик ОС занимается?

и да, на intel это плохая идея: при нагрузке на одно ядро процессор может повысить потребление (а значит и частоту) этого ядра за счёт остальных.

при «размазывании» одного потока по всем ядрам мы получаем такую картину:

• ядро не нагружено, процессор снизил частоту на нём;
• планировщик переключил нагрузку на него;
• процессор увидел и начал поднимать частоту;
• код всё выполняется;
• процессор таки поднял частоту;
• планировщик перенёс нагрузку на другое ядро.

на amd, думаю, поведение похожее.

[Fitrager]

Не знаю. ОС была Ubuntu 16.04. Процесс — склеивание двух видео в одно с синхронизацией времени, записанных системой прокторинга.

[Crazyvlad]

vmware лицензируется по сокетам, а не по ядрами

[dartraiden]

По блокам из 32 ядер, если быть точным. Т.е. 64-ядерный процессор считается как два процессора, а два 64-ядерных процессора потребуют 4 лицензии, хоть и занимают 2 сокета.

[Crazyvlad]

если быть точными, программа стартовала с 02 апреля 2020г. только. И если купил до 30.04 — только по CPU без учета ядер.
Вот ссылка

Ну и в статье CPU максимум 24 ядра ), так что упоминание о лицензированнии по ядрам не совсем корректно.

[1801BM1]

Ерусы процессоры хорошие, но там есть небольшая проблемка — L3 кэш вроде бы большой, но он физически не общий, а локализован кусочками по кластерам на 4 ядра. Если обращение в память попадает в «родной» кэш, то все хорошо, а вот если в удаленный — то беда, медленно все, примерно как в Интеле обращение к памяти другого процессора (на другом физическом сокете). В BIOS обычно даже настройка есть как Ерус разложить на сокеты и доложить системе. На старших Ерусах приходилось видеть 64 ядра в 16 сокетах на один физический процессор.

[VADemon]

Если обращение в память попадает в «родной» кэш, то все хорошо, а вот если в удаленный

PPS: Это, кажется, вообще о Zen 1, см. ниже.

В Zen 2 L3 cache делится между четырьмя локальными ядрами, 2 таких пакета образуют один CCX на восемь ядер. Доступ к L3 = ~39 тактов. По информации Anandtech, L3 между разными CCX больше не шарится (кстати, вы это сами подтверждаете (16(!) NUMA nodes=8ccx*2); пришлось бы делать round-trip через IO-Die и в случае промаха опять через IO-Die лезть в память).
Но что интересно, L2-cache в одном пакете CCX по сути является общим для 4-х ядер только на чтение:

If a core misses in its L2 cache and the L3 cache, and the shadow tags indicate a hit in another L2 cache, a cache-to-cache transfer within the CCX is initiated. CCXs are not directly connected, even if they reside on the same die. Requests leaving the CCX pass through the scalable data fabric on the I/O die.

А это, минуточку, ещё 512КиБ кэша с каждого ядра (+1536 в пределах пакета)

Ссылки: Zen2 wikichip и Zen2 Cache anandtech

PS: Я очень сомневаюсь, что доступ к памяти другого сокета вообще сравнится с временем доступа inter-CCX на Zen1.