Тест сервера на «Эльбрусе-8СВ»: результаты и впечатления от отечественного процессора
Сейчас как никогда важно иметь план «Б», поэтому взяли на изучение «Эльбрус-8СВ». В тексте — результаты и выводы о потенциале такого решения для наших дата-центров. С фото!
Привет! Меня зовут Максим, я работаю тестировщиком оборудования в Selectel Lab. Недавно взял на тест отечественный процессор «Эльбрус-8СВ». Он шел в комплекте с материнской платой «2Э8СВ-EATX» производства компании МЦСТ.
В рамках задачи собрал тестовый сервер произвольной конфигурации, установил операционную систему, настроил сеть и провел бенчмарк-тест. Подробнее об опыте в цифрах и нюансах рассказываю ниже. А здесь делюсь основным выводом.
Пока использовать отечественное «железо» непросто: слишком много препятствий.
Чтобы работа на «Эльбрусе» была удобной для конечного пользователя, нужно вложить много сил и времени. Например, придумать, как автоматизировать процессы, перекомпилировать необходимые программы, решить, как обойти существующие ограничения. Без катастрофической надобности эти вложения не будут оправданы.
Оговорюсь, что «Эльбрус 32-С» уже более реалистичен для использования в дата-центрах. Скорее всего, «допилят» и ПО. Но смогут ли его произвести по 7-нм процессу? Это вопрос будущего. Компания МЦСТ основана в 1992 году, а Intel — в 1968. Возможно, отечественная компания еще сможет нагнать конкурентов.
Далее будет базовый обзор. Возможно, он не такой подробный и щепетильный, каким мог бы быть. Нашей основной целью была быстрая оценка потенциала сервера на «Эльбрусе» в дата-центрах Selectel.
Навигация по обзору:
Сборка тестовой конфигурации
К нам в лабораторию приехала исключительно плата с процессором (процессор впаян в плату, без возможности апгрейда материнской платы) без радиаторов, вентиляторов и корпуса. Поэтому собирали кастомный сервер на «Эльбрусе».
В итоге тестовый конфиг выглядел так:
Корпус: 2U NVMe
- Процессор: «Эльбрус-8СВ»
- Матплата: «2Э8СВ-EATX»
- RAM: 8 шт. DDR4 32 ГБ 2933 МГц ECC Reg DIMM (MTA36ASF4G72PZ-2G9J3) Micron
- SSD: 1 шт. Micron 5300 Pro 1 ТБ
- HDD: 1 шт. ST4000NM0035 Seagate 4 ТБ
- SSD: Samsung 480 ГБ MZ7LH480HAHQ
- SSD: Intel 240 ГБ S4510
Для отвода тепла подошли радиаторы Intel BXSTS100A c активным охлаждением. Корпус взяли на два юнита от Supermicro 825TQ-R720/R740, так как изначально хотели добавить в конфиг GPU и NVMe. Правда, план не увенчался успехом.
Для тестирования показателей IOPS подключили HDD- и SSD-диски. Под руку попались ST4000NM0035 Seagate 4 ТБ и Micron 5300 Pro 1 ТБ. Эти диски проходили испытания по тестовым кейсам, поэтому были выбраны для сравнения показателей с другими тестовыми конфигами.
В надежде, что мы сможем протестировать SSD NVMe-накопители, подключили PCIe NVMe Host Bus Adapter AOC-SLG3-4E4T, но система NVMe-диски не увидела. То же самое случилось с SSD Samsung 970 EVO Plus NVMe M.2. Речь здесь об операционной системе «Эльбрус». Как работает сборка на других ОС, опишу ниже.
Установка операционной системы
Сначала решили установить нативную ОС «Эльбрус» на архитектуре e2k. Система ставится как с USB-носителя, так и c DVD. Также есть возможность установки по сети (PXE).
BIOS в системе нет, но есть его аналог — «Загрузчик», или boot. По факту, это оболочка, принимающая команды и параметры через командную строку.
Для работы в дата-центре это минус. Обычно первичная настройка платформы производится в BIOS, в том числе и Baseboard Management Controller (BMC). Операционная система устанавливается уже позже. Грубо говоря, при заказе выделенного сервера.
В случае сервера на «Эльбрусе», чтобы настроить BMC, сначала нужно установить «родную» ОС или другую систему, подходящую под архитектуру e2k.
А теперь представьте: в дата-центр поступило 100 серверов на «Эльбрусе». Как будем настраивать BMC? Правильно, сначала будем ставить ОС с флешки на каждый сервер и только потом настраивать BMC. Уйдет, мягко говоря, много времени. Есть конечно вариант с PXE-сервером, что немного облегчит задачу, но BMC придется настраивать все равно «руками» через ОС.
Остринки добавляет то, что мануалов по настройке BMC нет. И тут начинаются «танцы с бубном».
Как писал выше, настройка осуществляется только после установки ОС. Все из-за того, что в системе нет BIOS и на данной плате не реализован «мост» между интерфейсом BMC и «Загрузчиком» (аналогом BIOS). Подключение ноутбука напрямую в Ethernet-порт BMC результатов не дало. Достаю второй бубен.
После консультаций со специалистами МЦСТ получилось настроить BMC. Для этого соединил порты BMC и eth0 перемычкой патч-кордом, поднял DHCP-сервер на интерфейсе eth0 и указал пул из одного нужного нам IP-адреса. После этого BMC получил нужный нам адрес, а у нас появился доступ к веб-интерфейсу BMC.
Настройку BMC специалист дата-центра может производить только с ноутбука непосредственно в серверной, это не очень удобно. Работу системных инженеров с серверами стараемся максимально автоматизировать — так мы готовим серверы гораздо быстрее и исключаем возможные человеческие ошибки.
Настройка сети
Настройка сети схожа с настройкой в других Linux-системах.
Обзор операционных систем для e2k
Сделаю отступление и расскажу про подходящие операционные системы. Сейчас есть четыре ОС, которые поддерживают архитектуру e2k. Мы попробовали установить все.
ОС «Эльбрус». Установилась с USB, число программных пакетов — 1 256 шт., GUI неприветливый. Сетевой репозиторий отсутствует, только локальный. Тестовой версии ОС не предусмотрено — в комплекте с материнской платой и процессором не идет.
АLT Linux. Установка производилась с USB-носителя, интерфейс приятнее, чем в ОС «Эльбрус», количество пакетов — 17 211 шт. Также ограничено своим репозиторием, но уже имеет гораздо большее количество пакетов для разработки — например, Java, которого нет на ОС «Эльбрус». Также из преимуществ — наличие сетевого репозитория. Для записи на USB в комплекте к ОС идет скрипт.
Astra Linux 8.1, релиз «Ленинград». Установка не удалась. Причины уточняем у разработчиков ОС.
ЗОСРВ «Нейтрино». Дистрибутив ОС нам не предоставили, пояснив, что ЗОСРВ «Нейтрино» и ЗОСРВ «Нейтрино-Э» нечасто применяется на серверах. В отличие от, например, бортового промышленного оборудования, решающего задачи в режиме реального времени. По заявлению производителя архитектуру e2k данная ОС поддерживает.
Программы под ОС «Эльбрус»
Возвращаемся к нашей конфигурации. После настройки платформы добрались до самой ОС «Эльбрус». Здесь сразу же столкнулись с тем, что сетевых репозиториев нет, и стек скомпилированных программ под архитектуру e2k ограничивается одним DVD-диском, идущим в комплекте с операционной системой. В нашем комплекте оказалось 1 256 программ, со списком можно ознакомиться по ссылке. Все, что потребуется сверх этого списка, придется «пересобрать» или написать самим.
Для решения задачи совместимости с ПО для платформы x86 в МЦСТ разработали проприетарный бинарный транслятор. Он работает в двух режимах, чем-то напоминающих гипервизор. Первый реализован в Lintel, второй — в «RTC». Последний работает под управлением уже запущенной операционной системы.
В приложенном списке мы не увидели Docker, Prometheus, Java и еще очень многих пакетов, необходимых для нормальной работы сервера в дата-центре. На данный момент на e2k реализована только одна СУБД — PostgreSQL, которая будет работать вне режима бинарной трансляции. Остальные СУБД и ПО, которого нет в комплекте с ОС, можно запустить только через бинарный транслятор. Чтобы перекомпилировать отсутствующие инструменты для «Эльбруса», потребовалась бы целая команда.
Из плюсов: есть необходимые пакеты для разработки ПО, Python, Git, библиотеки и компиляторы от МЦСТ.
Подготовка к тестам
Для проведения тестов мы использовали бинарный транслятор приложений «RTC» и дистрибутив Ubuntu 22.04.
Существенный минус «RTC»: производительность, которой и так немного, будет ограничена. По тестам из разных источников она падает до 30% в зависимости от ПО.
С дистрибутивом тоже пришлось помучиться. После развертывания Ubuntu-server 20.04 x86 возникла проблема с системным временем. Происходит отставание системного времени от реального. Для серверного оборудования это критично. Есть предположение, что это из-за системы бинарной трансляции.
Из подключенных 32 планок RAM используется только 3. По информации от МЦСТ в режиме бинарной трансляции используется только один КПИ (можно посмотреть на схеме).
Соответственно, вся периферия, завязанная на КПИ_1, в этом режиме работать не будет.
Результаты бенчмарк-теста
Мы провели бенчмарк-тест Geekbench5 в режиме бинарной трансляции и получили такие результаты:
Видно, что пока «Эльбрус» в режиме бинарной трансляции пытается догнать по показателям AMD Ryzen 5 2400G. Но это десктопный процессор, релиз которого произошел в феврале 2018 года. О конкуренции с современными серверными процессорами речи пока не идет.
Также «Эльбрус» догоняет по бенчмаркам (и даже перегоняет по image compression) Intel Xeon E3-1225, выпущенный в 2014 году. Сравнение с ним на картинке ниже.
Более подробно по ссылке. Кстати, с каким серверным процессором сравнили бы вы «Эльбрус-8СВ»?
Эпилог
Как можно понять по результатам тестов, на данный момент препятствий для использования «Эльбрус-8СВ» в дата-центрах Selectel более, чем достаточно. В будущем постараемся протестировать «Эльбрус» другим софтом, написанным под архитектуру e2k.
Надеемся, что появится поддержка NVMe и современных GPU. И что МЦСТ будет развиваться, чтобы далее мы смогли использовать эти решения в повседневных задачах.
Подпишитесь на блог Selectel, чтобы не пропустить новые обзоры, новости и кейсы из мира IT и технологий.
Читайте также:
Комментарий недоступен
Частота не зависит от тех процесса напрямую. Частота больше зависит от сложности выполнения инструкций. Ну и частота x86 и частота ARM в целом несравнимы. У ARM фиксированная ширина инструкции, у x86 нет. Это накладывает дополнительные расходы на декодинг. Можно сделать тупой процессор с высокой частотой, но более медленный x86 внутри будет выиграть просто за счет того, что за такт x86 будет выполнять больше внутренних операций. В целом Эльбрус может и x86 в некоторых математических операциях выигрывать, но из-за особенностей архитектуры general purpose задачи будут проигрывать из-за прерываний.
не в декодере дело, а в том, что арм все инструкции выполняет на регистрах, а x86 ещё и в памяти. от этого много сложностей. на сколько знаю никто на декодер не жалуется, хоть он конечно на много сложней.
Все операции невозможно производить в регистрах. Ну и x86 дает только ограниченный набор регистров для пользователя. На самом деле под капотом их сильно больше. Ну и register renaming давно уже изобрели.
понятное дело, что регистров больше чем есть "официально" для хранения промежуточных результатов и т.д., но а мне то какое дело до этого? не могу сказать, что читал доки ARM но читал, что там как раз нет сложных инструкций по работе с памятью, только простые типа загрузить в регистр, выгрузить, залочить и т.д. почему вы решили что в таком случаи невозможно создать процессор мне не ясно. А раз все операции на регистрах (для исполнительных блоков) то проще заполнить конвейер и реордеринг инструкций организовать. А в x86 завязка на ram сильно усложняет жизнь и вносит много непредсказуемости, там вроде даже есть инструкции которые 14 тактов из-за этого могут занимать.
Сходите почитать все же что такое register renaming. Они не для хранения промежуточного результата. Это один из компонентов параллелизма уровня самого процессора, т.е. инструкций.
там как раз нет сложных инструкций по работе с памятью, только простые типа загрузить в регистр, выгрузить, залочить и т.д.Это отличиях RISC от CISC, но сейчас это уже не важно. CISC x86 это обертка над RISC ядром. x86 внутри себя оперирует уже более мелкими инструкциями, что значительно быстрее, чем фетчить и постоянно вытеснять кэш более мелких инструкций.
почему вы решили что в таком случаи невозможно создать процессор мне не ясно.Где я это писал? Я писал о том, что частота не всегда показатель эффективности. На разных архитектурах частоты могут быть разными, но в конечном счете результат может быть в пользу тех, что имеют меньшую частоту.
А раз все операции на регистрах (для исполнительных блоков) то проще заполнить конвейер и реордеринг инструкций организовать.Столлы появляются на загрузке данных в регистры, реордеринг, префетч и спекулятивное исполнение решают именно эту задачу. Это не зависит от того будет у вас 20 регистров или 5. Зависит от того как процессор внутри решит как бороться со столлами.
А в x86 завязка на ram сильно усложняет жизнь и вносит много непредсказуемости, там вроде даже есть инструкции которые 14 тактов из-за этого могут занимать.Вы видимо вообще не представляете что такое процессор. Все процессоры завязаны на RAM. Только где-то это отдано компилятору, чтобы он инструкции загрузки данных выставлял, а где-то процессор берет на себя необходимость префетча и прочее. Сколько выполняется инструкция не имеет значения, если сравниваемая архитектура будет выполнять те же действия, но уже в виде 14 более мелких инструкций. Это и есть главное отличие RISC от CISC. Условно говоря, у вас может быть расчет CRC сделан через полиномиальное перемножение(SIMD) на ARM и одну инструкцию в x86. Каждый шаг в ARM будет занимать один цикл, а в x86 одна инструкция будет занимать 3 цикла. Но в ARM нужно будет сделать 4 перемножения. В итоге ARM все равно проиграет. Но это пример из головы, реально все будет не так для конкретных инструкций. Но еще есть кэш инструкций и в ARM он будет быстрее вытесняться, на это тоже нужно закладываться.
:) "Вы видимо вообще не представляете что такое процессор. "
я вообще-то программист, дипломированный даже, а вы кто?
"Сходите почитать все же что такое register renaming."
я же написал и т.д., потому что для много чего надо, а выглядело так, словно вы понтануться пытались и удивить меня.
"CISC x86 это обертка над RISC ядром. x86 внутри себя оперирует уже более мелкими инструкциями, что значительно быстрее, чем фетчить и постоянно вытеснять кэш более мелких инструкций."
это вообще полный бред + враньё откровенное. архитектор первого пентиума в кворе ясно всем написал, что микро код пентиумов и всех следующих процов до сегодняшнего дня это никакая не обёртка над RISC. это низкоуровневые команды типа "включить такой-то блок", активировать "такую то часть цепи", кстати может и обновляться если баг найдут. Он ясно написал что это никакой ни RISC и близко, это по сути битовый вектор большой длинны, фиксированной (и набор таких векторов) и каждый раз его формат меняется с выходом новой микроархитектуры как минимум. Чем раньше байка о том, что "внутри CISC всё давно по сути работает как в RISC" пройдёт - тем всем будет лучше. В том то и дело, если бы всё было иначе, то не было бы и разницы между продуктами, верно?
"Столлы появляются на загрузке данных в регистры, реордеринг, префетч и спекулятивное исполнение решают именно эту задачу."
что такое столлы? по анлийцки пожалуйста. а то я не очень понимаю какие могут быть существенные задержки при загрузке чего-то из кэша первого уровня в регистры :) все задержки связаны или с зависимостью по данным (ждём результат с другого порта выполнения) или задержками при чтении из памяти.
"Сколько выполняется инструкция не имеет значения, если сравниваемая архитектура будет выполнять те же действия, но уже в виде 14 более мелких инструкций."
вижу вы ничего не поняли, или не разбираетесь в теме в принципе, ещё раз повторяю: набор команд CISC и то что некоторые инструкции выполняются 14 тактов создают огромную проблему для всего что вы перечислили: реордеринг, спекулятивное исполнение и т.д. В CISC добавили инструкции которые сами по себе делают нужную работу, наверняка даже делают её сильно лучше чем можно на RISC (я джавист а не C++ программист, могу только приблизительно рассуждать и на основе того, что читал по теме), но проблема в том, что они будут попадаться в коде не часто, а общее взаимодействие и возможности по оптимизации выполнения процессором из-за этого сильно проседают. Это не самая очевидная вещь, можно сказать принципиальное решение при проектировании архитектуры и добавления команд, тем более что всё развивалось постепенно и по этому интел потихоньку зашёл не туда, хотя там много умных людей.
Ещё раз: основное различие это то, что у RISC нет команд для сложной работы с RAM, из-за этого реордеринг и как следствие конвейер работает и оптимизируется лучше (зато похоже многопоточный код работает хуже типа атомарного инкремента). А если нет "дыр" в работе то вот вам и общая производительность выше. Набор команд CISC слишком не очевиден по причине этих "14 тактов" и забить конвеер полностью сложнее, просто потому что не всегда понятно как. Не каждый код можно зареордерить аж на 14 тактов (а спекулятивное исполнение может оказаться бесполезным по итогу, как повезёт). Чтобы как-то решить эту проблему придумали гипер-трейдинг, чтобы воровать работу у другого логического потока и быстро переключаться, всё из-за дыр в конвейере. Глобально разница в этом. + Apple конечно ещё добавила плюшек типа общей памяти вместо RAM+Graphic RAM (а гонять туда-сюда не очень то и бюджетно).
Написал свою реализацию 8086, немного копал 386 и MIPS/ARM на Verilog. Этого достаточно?
это вообще полный бред + враньё откровенное. архитектор первого пентиума в кворе ясно всем написал, что микро код пентиумов и всех следующих процов до сегодняшнего дня это никакая не обёртка над RISC. это низкоуровневые команды типа "включить такой-то блок", активировать "такую то часть цепи", кстати может и обновляться если баг найдут.Я не знаю что там где и когда писал архитектор первых пентиумов, современные Intel разбивают инструкции на микрооперации. Эти микрооперации могут быть "отлиты" как в ASIC, так и иметь реализацию в виде firmware("микрокода"). https://en.wikipedia.org/wiki/Software_Guard_Extensions там внутри есть публикация https://eprint.iacr.org/2016/086.pdf которая объясняет как микрооперации работают.
Он ясно написал что это никакой ни RISC и близко, это по сути битовый вектор большой длинны, фиксированной (и набор таких векторов) и каждый раз его формат меняется с выходом новой микроархитектуры как минимум. Чем раньше байка о том, что "внутри CISC всё давно по сути работает как в RISC" пройдёт - тем всем будет лучше. В том то и дело, если бы всё было иначе, то не было бы и разницы между продуктами, верно?Нет, не верно. Что за верктор? Конвейер что ли? И чем будет лучше? Между продуктами всегда будет разница, хотя бы потому, что у них разное легаси.
что такое столлы? по анлийцки пожалуйста. а то я не очень понимаю какие могут быть существенные задержки при загрузке чего-то из кэша первого уровня в регистры :) все задержки связаны или с зависимостью по данным (ждём результат с другого порта выполнения) или задержками при чтении из памяти.https://en.wikipedia.org/wiki/Pipeline_stall А как данные попадают в L1? Всегда ли они попадают в L1. Почему у процессора есть L2/L3? Что будет если процессор промахнется с предсказаниями и в L1 не будет нужных данных?
В CISC добавили инструкции которые сами по себе делают нужную работу, наверняка даже делают её сильно лучше чем можно на RISC (я джавист а не C++ программист, могу только приблизительно рассуждать и на основе того, что читал по теме), но проблема в том, что они будут попадаться в коде не часто, а общее взаимодействие и возможности по оптимизации выполнения процессором из-за этого сильно проседают.Какие оптимизации? У процессора есть кэш инструкций отдельно от кэша данных. У x86 инструкции более короткие по длине и более емкие по функциональности. Соотвественно в кэше x86 бранч предиктор найдет куда больше полезной информации для ветвления, чем у ARM. А дальше процессор уже ничего не оптимизирует. Он может найти фаст пас для какой-то операции, но при этом что-то изменять он не может. Для оптимизации используются компиляторы с LTO и прочим.
https://www.quora.com/Why-are-RISC-processors-considered-faster-than-CISC-processors/answer/Bob-Colwell-1
вот тот пост, о том что никакого RISC или чего-то подобного внутри CISC нет
Вообще-то он говорит совсем другое. В тексте написано, что люди путают ISA, которую может генерировать компиляторы и микроархитектуру, которая доступна только самому CPU. Да, никто не спорит что ISA у него не RISC. Ну и формально было бы правильнее говорить про RISC-подобное ядро. В этом-то весь его посыл.
интересно вы читаете по англ: "The micro-op idea was not “RISC-inspired”, “RISC-like”, or related to RISC at all. ", "Intel’s x86’s do NOT have a RISC engine “under the hood.”" и ваше "Ну и формально было бы правильнее говорить про RISC-подобное ядро." :)
Ok, на уровне микро операций неправильно говорить о RISC ядре.
Так что там с кэшами и оптимизациями внутри процессора?
Intel зашел ровно туда, куда и нужно. У них есть легаси ISA, а для этой ISA есть ядро, которое может быть CISC, RISC или вообще VISC. У них даже были попытки сделать транслятор CISC на VLIW. Уж что, а архитектура в x86 отточена максимально эффективно. Вы наверное просто не слышали про Thumb у ARM. Вот это явно чуваки не туда зашли.
Ещё раз: основное различие это то, что у RISC нет команд для сложной работы с RAM, из-за этого реордеринг и как следствие конвейер работает и оптимизируется лучше (зато похоже многопоточный код работает хуже типа атомарного инкремента). А если нет "дыр" в работе то вот вам и общая производительность выше.Не у RISC, а у ARM. Реордеринг зависит от того какая модель памяти используется, какие гарантии предоставляются. У ARM она более релаксед, у x86 более строгая. Поэтому часто лок-фри код для x86 не работает без добавления костылей для ARM. И все случаи нужно мерять, а не на словах рассказывать. Есть ситуации когда явные локи выигрывают, есть случаи когда атомики выигрывают. Есть ситуации, когда ARM'у нужно дополнительно насовывать инструкции, чтобы не было гонки по памяти.
Набор команд CISC слишком не очевиден по причине этих "14 тактов" и забить конвеер полностью сложнее, просто потому что не всегда понятно как.Всегда понятно как. Как погроммист написал, так и забивается. Процессор не должен делать никакой самодеятельности.
Не каждый код можно зареордерить аж на 14 тактов (а спекулятивное исполнение может оказаться бесполезным по итогу, как повезёт).При чем тут вообще реордеринг?
Чтобы как-то решить эту проблему придумали гипер-трейдинг, чтобы воровать работу у другого логического потока и быстро переключаться, всё из-за дыр в конвейере.Да? Если все так плохо у Intel, то зачем это тащат в ARM?
Глобально разница в этом. + Apple конечно ещё добавила плюшек типа общей памяти вместо RAM+Graphic RAM (а гонять туда-сюда не очень то и бюджетно).Это настолько древнее решение, что мой первый ноутбук с интегрированной карточкой кажется это умел. На мак я перешел лет 15 назад, следовательно сращиванию RAM и GPU RAM уже больше 15 лет.