Что лучше — ARM или x86? Отвечаем на вопрос и делимся результатами бенчмарков

Вокруг ARM-процессоров много шума. Они восстребованы не только у производителей смартфонов, но и у облачных провайдеров. В подборке собрали материалы с испытаний Ampere Altra™ от Selectel Lab. Вы узнаете о трудностях при работе с неадаптированной сборкой Arch Linux и будущем ARM в северном сегменте.

Используйте навигацию, если нет времени читать текст целиком:

→ Действительно ли за ARM-процессорами будущее?

→ Обгонят ли ARM-процессоры х86 по производительности?

→ Реально ли добавить серверы на ARM в дата-центры?

У процессоров на базе x86 закрытые решения: невозможно получить доступ к информации об архитектуре и изменить существующую конфигурацию. ARM же, по сути, только ядро, причем в виде документации. Пользователь покупает систему команд и получает рекомендации, как и с какими конвейерами, системами питания и драйверами внешних интерфейсов ее использовать. А после — выбирает технический процесс и производителя. По сути, ARM — это некоторое спасение от вендорлока.

Узнайте больше о развитии платформ →

Перспективы развития ARM-процессоров

Серверные процессоры на базе ARM появляются не так массово, как чипы для мобильных устройств. Однако сейчас технологические компании вкладываются в разработку собственного оборудования. Так, Ampere активно продвигает свои процессоры, которые догоняют по характеристикам Graviton от AWS. Google и Microsoft переходят на разработку собственных чипов, снижая свою зависимость от Intel, а Amazon и Alibaba утверждают, что к 2025 году 25% всех новых инстансов будут на их собственных ARM-процессорах.

Какие сейчас основные трудности работы с ARM?

Проблемы с версиями VM и библиотек под ARM. Один из клиентов Selectel, который тестировал ARM, столкнулся с отсутствием в Arch библиотеки libc, которая поддерживает C++20, тогда как Arch на x86 содержит правильную библиотеку. Вопрос решили переходом на Ubuntu.

Поведение видеокарт с ARM нестабильно. Мы сталкивались с нестабильным поведением видеокарт и до конца не понимаем, как это решить. Поэтому пока клиенты с видеокартами останутся на x86.

О других особенностях и результатах клиентских тестов читайте по ссылке →

Чтобы ответить на этот вопрос, мы взяли на изучение сервер GIGABYTE E252-P30 с 80-ядерным процессором Ampere Altra. Хотели убедиться, насколько ARM отвечает заявленным характеристикам, поэтому протестировали его и сравнили с сервером на процессоре от AMD (точнее на двух CPU) — c 64 ядрами в сумме.

Бенчмарки ARM

Мы провели тест на производительность с помощью Geekbench 5. На сервер решили установить Ubuntu, так как это наиболее частая в использовании ОС для ARM. В методиках испытаний использовали Ubuntu 22.04.01 LTS 5.15.0-50-generic aarch64 — свежий дистрибутив Ubuntu под архитектуру aarch64.

Что у нас в сборке:

Мы выяснили, что в однопоточном режиме процессор выдает низкие результаты. Зато в многопоточном демонстрирует высокую производительность. Так, ARM-процессор будет полезен в высокопроизводительных вычислениях, если для клиента это основная задача.

В Multi-core режиме ARM-процессор обгоняет x86 по всем критериям. Особенно это заметно в параметрах с параллелизацией задач. Тут работает закон «чем больше ядер — тем лучше». При этом предпочтение отдаются физическим, а не гипертрейдинговым ядрам, с которыми работает x86-архитектура. Поэтому в ряде критериев — например, гауссовском размытии, HDR, Camera и т.д. — ARM лидирует очень уверенно.

Мы также измерили скорость, энергопотребление и провели стресс-тест. Нам было важно узнать, подходит ли ARM-процессор от Ampere для эксплуатации в дата-центрах.

Больше результатов тестов читайте в статье →

Наша линейка серверов пополнилась конфигом Ampere Altra Max M128-30 с ARM-процессором внутри. Поскольку мы стараемся сдавать выделенные серверы быстро, на помощь приходит кастомная сборка Arch Linux для автоматизации процессов. Мы планировали настроить дистрибутив для ARM за две недели, но возникли проблемы.

Что не так со сборкой?

1. Разработчик продублировал большинство классов, поменяв переменные значения на необходимые для архитектуры aarch64. Из-за этого в сборке не было артефактов для загрузки сервера в режиме UEFI.

2. Мы хотели использоваться chroot с поддержкой кросс-архитектурной сборки, но утилита ломалась во время «добавления» пакетов «внутрь» образа.

3. Мы сильно кастомизировали наш служебный образ, поэтому не могли воспользоваться готовыми бинарными пакетами в репозиториях.

Читайте, как мы настраивали автоматическую загрузку сервера →

Как мы устранили проблемы

Модифицировали сборочные скрипты archiso-aarch64. А именно — изменили класс, который использовался при сборке образа под legacy-режим загрузки.

В часть, ответственную за сборку UEFI-артефактов, импортирован класс, отвечающий за упаковку ядра и initramfs. Мы добавили в строку 622 _run_once _make_boot_on_iso9660. Это позволило нам получить необходимые артефакты для сетевой загрузки.

Запустили GitLab-runners на Raspberry Pi 4. В качестве executor в GitLab-runner используется Docker. Это сильно отличается от сборки x86-образа, где используется libvirt и QEMU. Последняя работает пока крайне медленно в режиме эмуляции aarch64, поэтому необходим более простой в настройке исполнитель. Мы выбрали RPi4.

Переписали скрипт автотестов и временно отказались от некоторых фич для arm64. Например, автоматической прошивки материнских плат и периферии, а также автоматической настройки BMC.

Отвечая на вопрос в заголовке, реально! На первый взгляд задача кажется несложной из-за минимальных отличий между aarch64 и x86_64, но чем глубже погружаешься, тем больше открывается нюансов. Поэтому мы принимали решения через практические эксперименты и опирались на опыт наших коллег. Зато, если у вас есть похожая задача, вам не обязательно проходить весь этот путь самостоятельно.

Подробная инструкция по настройке Arch Linux для ARM →

#selectel #tdarticle #arm #обзор