Почему ARM? Перспективы платформы в серверном применении

«Когда-то небольшой английский стартап был простой игрушкой для сборки PoS-терминалов. Затем — компонентом для умных датчиков, connected- и более сложных embedded-устройств, где без операционной системы уже не обойтись. Еще позже — основой для большинства мобильных устройств. И теперь каждый владелец смартфона знает, что под его капотом — ARM». 

Меня зовут Игорь Лепихин, я руководитель направления аппаратного обеспечения в Selectel. Мы с коллегами уже писали про тестирование и сборки под ARM-архитектуры. Но почему именно ARM? И способен ли он обогнать Intel и AMD в сегменте серверной аппаратуры? В статье как раз об этом и поговорим.

Тренд на открытую архитектуру

Что есть сейчас?

Пока все неплохо. Рынок делят Intel и AMD, под их глубоким капотом одно и то же процессорное ядро — x86-xx, а доминирующая концепция на рынке — Software-Defined Everything, SDx. Это значит, что любые сложные бинарники должны вести себя предсказуемо, а серверное ПО, скомпилированное под AMD, — работать на Intel и наоборот. Де-факто можно смело утверждать, что ядро x86-xx достигло своего полупроводникового дзена: любой серверный софт изначально пишут и оптимизируют именно под x86.

Не было бы печали если бы не вертикальная модели всего, что хоть как-то связано с x86. Как говорится, Windows тому свидетель…

Посмотрим, как развивались программно-аппаратные комплексы — серверные и десктопные ПК.

Начало и развитие платформ

В 70-80-х годах, когда люди осознали, что на центральных процессорах можно делать не только калькуляторы, бытовало мнение, что продав много персональных компьютеров, можно заработать много денег. Разработчики-энтузиасты думали, что все очень просто: покупаешь процессор Z80 или Motorola 6800, по документации разводишь плату, ставишь на нее периферию и можно продавать. Но это никто не покупал…

Потребителям было важно, чтобы компьютер поддерживал много прикладных программ, и чем больше — тем лучше. Но для них нужно какую-никакую, но операционную систему написать. И нанимает разработчик компьютера программиста, который знает Assembler (иногда C), чтобы тот написал ОС. Так и появились AmigaOS, Atari TOS, OpenVMS и другие.

У каждой ОС был свой бинарный интерфейс (ABI). И программист должен был не только помнить, для какой платформы он пишет офисный пакет, так еще и знать ABI. Потом все это собиралось в бандл и разработчик компьютера презентовал: «У меня новый процессор на 200 КГц быстрее и на 16 КБ больше по памяти, есть набор прикладных программ, которые можно запустить. Покупайте!»

Как итог: программист в тени, но счастлив, что к нему пришел разработчик компьютера и заказал программу. Рынок этого программиста ограничен штуками компьютеров, которые будут произведены и проданы. И он начинает задумываться: «Эх, если бы мой офисный пакет купил бы он, и он, и еще вон тот… Но у первого AmigaOS, у второго Atari, а у третьего IBM PC…»

Но невозможно же содержать столько специалистов, которые будут разрабатывать и поддерживать все комбинации платформа-ОС. Вдобавок аппаратные платформы стали достаточно мощными и сложными, фичи дешевле было разрабатывать в программной реализации. Поэтому и появилась концепция SDx и софт вышел на первый план: платформа должна быть ориентирована под него, не наоборот.

Развитие x86

Железо без софта — это просто красивый элемент интерьера, притом дорогой в производстве. Когда вендоры это поняли, началась гонка по разработке «архитектурного стандарта». Победителем вышел IBM PC со своей x86: архитектура получила распространение, обогнав остальные платформы за счет своего бандла с небольшой малоизвестной компанией Microsoft.

Программистов под x86 становилось все больше, для Motorola 68000 — меньше. Отдельная история про OS/2: она долго жила параллельно в этой же вертикальной вселенной. При всей нежности, которую я к этой системе испытываю, рынок сказал свое слово — и она тихо ушла, передав все лучшее в Windows NT. Наступила целая эпоха доминирования архитектуры x86. 

С ПО, казалось бы, все очевидно: Windows на ПК, а Unix, Solaris и им подобные — на серверах. Но есть одно «но»: разработка стала доступней. Появились энтузиасты, готовые собирать софт самостоятельно, по книжкам. Примерно так и появился Linux и вообще концепция свободного ПО. Качество его, конечно, так себе: поддержка и багофикс стоили денег. И чтобы развивать подобные проекты, люди начали объединяться в сообщества — и свободное ПО стало развиваться семимильными шагами, предложив рынку альтернативу для закрытых решений.

Тем временем в дата-центрах внезапно оказалось, что RISC-архитектура отвечает потребностям серверного сегмента. К этому времени стало понятно, что задача сервера — быстро принять, обработать и передать данные. Для этого не нужна трехэтажная математика на FPU, достаточно быстро и параллельно оперировать с пакетами данных до 1 КБ. С этим хорошо справляется RISC. 

С помощью RISC и его суперскалярности достигли высокой эффективности в обработке данных. Для сравнения: операция умножения на RISC занимала 1 такт, а не десятки, как в случае x86. Также на базе RISC появилось много архитектур — например, PowerPC, SPARC и DEC Alpha (Alpha Silicon) — да-да, именно кластер из пары сотен Alpha Silicon красиво «утопил» Титаник. И для каждой из них была своя Unix-сборка (или Solaris, хотя это одно и то же). Спасибо C и нативным компиляторам: несложный для того времени серверный софт пересобрать под новую платформу не представляло труда. 

Однако x86 становилась дешевле, а поддержка платных сборок на других аппаратных платформах — дороже. И в какой-то момент произошло всего «не x86» из серверного сегмента. Роста производительности новых чипов хватало, специалистов на x86 все больше. Поэтому архитектура закрепилась и в серверном сегменте. 

Плюс тогда возник тренд на открытость: начали открывать исходники бывших Unix-систем, а железо стало отделяться от софта. Linux занял доминирующую позицию со своей бизнес-моделью «хочешь — плати, не хочешь — мучайся сам». 

Что сегодня? Оказывается, зарабатывать можно не только на продаже софта, но и на сборке и обработке информации, притом гораздо больше. Яркий пример — модель с техподдержкой за деньги. Специалист продает информацию о том, что нужно сделать клиенту для решения своей проблемы. 

Но если информация стоит денег, ее нужно защитить, чтобы у третьих лиц не было к ней доступа. А как могут украсть информацию? Да просто понаставят «закладки» в банковском ПО, в американских чипах, и личный счет обнулится. Это, конечно, преувеличение, но доля правды есть. Поэтому формируется тренд на открытость, чтобы любой независимый эксперт мог посмотреть внутрь программы и hw-архитектуры и подтвердить, что «закладок» нет и информация уходит куда надо.

Несмотря на тренд, до сих пор остаются закрытыми Microsoft и коммерческие серверные Unix-сборки. Но! — в персональном сегменте ноутбуки и десктопные устройства все больше уступают мобильным, где на свободном и открытом Linux «крутятся» библиотеки AOSP. Как минимум, их исходный код можно скачать, проанализировать и проверить, сколько на уровне ОС «закладок».

Проверьте ARM-процессор в своих задачах бесплатно

Сервер с 128-ядерным процессором Ampere® Altra® Max M128-30 и 256 ГБ DDR4 памяти уже в Selectel.

Как появился ARM и какое у него будущее

Решения на базе x86 закрыты: у рядового пользователя и даже профессионального разработчика программно-аппаратных комплексов нет доступа к большей части информации об архитектуре. Вы можете купить только процессор синего или красного цвета, выбрать чипсет и установить в плату, сделанную под конкретного вендора. Но возникают вопросы…

Что за firmware, которое регулярно обновляют Intel на своих чипсетах? Почему не раскрывает ни функционал, ни исходный код? Отсутствие ответов на эти вопросы продолжает подкидывать дрова в костер открытости архитектуры.

Разработчики подумали: «Как было бы хорошо взять ядро (систему команд), прикрутить желаемый конвейер, драйверы интерфейсов и поставить на производство там, где захочу». Но эта концепция невозможна для x86. Но к тому моменту уже был ARM и с ним таких проблем не было, поэтому он укоренился.

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

К слову, можно и на Микроне в Москве сделать ARM v9-based процессор. Но все существующие IP-блоки нужно будет написать самостоятельно под 90-нм процесс. Правда, процессор получится очень большой…

Что будет с платформами в будущем. Сегодня самая открытая трендовая архитектура — RISC-V. И среди моих коллег есть мнение, что она может состояться как standalone-ядро центральных процессоров от нескольких открытых вендоров. Или привести к созданию application specific-ядер и потери бинарной совместимости между процессорами на базе RISC-V.  

Я же думаю, что Intel останется как нишевой продукт для специфического применения и legacy-задач, которые никуда не денутся. Для примера: PPC и DEC Alpha до сих пор можно встретить внутри устройств, а Motorola 6800 вообще используют в самолетах Boeing. Массовой станет архитектура на базе ARM, а RISC-V пройдет путь от встраиваемых устройств до серверов и потеснит ARM в далеком будущем. Тренд на использование открытого ПО сохранится — ждем, когда в Microsoft откроют исходники Windows 11.

ARM в серверном сегменте: области применения, проблемы и перспективы

Наверное, сейчас можно сказать, что серверный сегмент — это апогей развития любой аппаратной платформы, любого процессорного ядра. Решение должно быть надежным, масштабируемым и быстрым в обработке данных. 

Серверные процессоры на базе ARM сейчас появляются не так массово, как чипы для персональных устройств. Тут их можно разделить на две категории: свободные решения для разработки и проприетарные — от компаний, управляющих дата-центрами. 

• Проприетарные: Graviton от AWS, Yitian от Alibaba
• Свободные: Ampere, Kunpeng от Huawei

Тот факт, что AWS и Alibaba вкладываются в разработку собственных чипов, добавляет оптимизма насчет перспектив ARM. Кто разрабатывает сами серверы для AWS и Alibaba — неизвестно. Возможно, они делают это самостоятельно или через подрядчиков. Если через них, то есть шанс найти дизайн-гайды и взять такой сервер на тест.

Альтернатива проприетарным чипам — открытые решения. Сегодня Ampere активно продвигает свои чипы и догоняет по характеристикам Graviton от AWS. Gigabyte и Inspur на этих процессорах уже доступны в различных конфигурациях — их можно протестировать и арендовать в Selectel. 

Непонятна ситуация с Huawei. Их Kunpeng, будучи неплохим решением, похоже, стал жертвой вертикального бамбукового стержня: и чип, и сам сервер разрабатывают только в Huawei. Возможно, как любят в Поднебесной, сначала будет удовлетворен внутренний спрос, а зачем уже компания выйдет на открытый рынок. Мы пытались протестировать платформу в 2020 году, но на тот момент, наверное, не все были к этому готовы. 

Резюмируя: готовые решения на ARM только появляются. Вот, как развивается на них спрос в дата-центрах:

Сомнений нет, что драйвером ARM являются AWS и Alibaba, которые заявляют, что к 2025 году 25% всех новых инстансов будут на ARM. Не отстают и Azure c Google, которые прогнозируют то же самое, но пока что не разрабатывают собственные чипы, а используют труды Ampere. Google вообще планирует отказаться от инстансов на x86 в течение десяти лет. 

AWS, конечно, опережает Ampere и идет в ногу с новыми продуктами на x86, например по поддержке DDR5 и PCIe5. Ampere только сейчас выходит на рынок с этими решениями, тогда как AWS еще летом объявил, что его новые инстансы поддерживают эти новые стандарты.

Кто использует ARM

Сервер привезли, собрали и поставили — надо его как-то продавать. Большинству клиентов нет разницы, какая архитектура сверкает у них под капотом. Но для сервис-провайдеров смена архитектуры может обернуться проблемой с несовместимостью аппаратной платформы и программного обеспечения. Поэтому должны быть серьезные причины перехода: новая архитектура должна решать пользовательские задачи, ведь продавать только количества ядер уже не получится. 

С решением проблем с совместимостью аппаратной платформы и ПО помогут компании вроде AWS. Уже сейчас компания публикует перечни клиентов, которые выбрали решения на базе ARM — от глубокой инженерной разработки и тяжелого финтеха, до стриминговых и Nginx-серверов. Мы собрали статистику, проанализировали перечни и получили такое распределение: 

80% клиентов на ARM используют Java, V8 и Python — все, что на базе виртуальных машин. Оставшиеся 20% — инструменты, написанные на компилируемых языках. 

Проблемы платформы в дата-центрах

Чтобы Java работала на ARM, нужно портировать ее виртуальную машину JVM. И то же самое сделать с V8, если нужно запустить приложение на JavaScript, или PVM, если приложение на Python. Тогда можно получить прирост производительности, за который клиенты готовы платить, судя по данным AWS. 

Трудности возникают с софтом из оставшихся 20%. Потому что он написан на компилируемых языках. И если JVM — это один большой бинарник, который достаточно один раз портировать, то софт на базе C++ — это один большой и много маленьких бинарников для решения узких бизнес-задач, которые нужно портировать по отдельности. И {_gcc —arch=aarch64_} работает тут почти никогда, поэтому и возникают основные сложности. 

Дело еще в том, что C++ и его очередной убийца Rust обретают новую жизнь. Сегодня основной cash-flow — это обработка данных, то есть, например базы данных. И когда мы что-то достаем из таблицы через SQL-запрос, запускается нативный код, написанный когда-то на C. Если мы хотим обучить нейронку, то используем библиотеки вроде Tensorflow. Да, Python хоть и портирован на ARM, но это всего лишь интерфейс, а его ядро — нативный код на C++. То же самое и с играми, разработанными на Unity и Unreal.

В общем, весь performance critical — это нативный код и пока нет предпосылок, чтобы JVM или — кхм — V8 приближались по производительности. В том, что обработка данных, AI и ML будут развиваться, сомнений нет. И вряд ли можно утверждать, что доля нативных приложений останется на таком низком уровне. Технически нужно быть готовыми, что настанет день, когда 99% клиентов, будут использовать серверы на ARM. Возможно, я преувеличил, но проверить нужно. 

Я часто сравниваю сервер на ARM с автомобилем на водородной ячейке. Вряд ли его купят, если просто поставить в автосалон. Его купят, если ты расскажешь, как и где эти водородные ячейки заправлять и сколько это будет стоить. Вот этим мы и занимаемся: проверяем и рассказываем клиентам, с чем они могут столкнуться на новой платформе и как выйти в профит.

В силу специфики бизнес-модели, ARM не может контролировать, где и как используется его технология. Свобода выбора стимулирует конкуренцию и развитие «обвязок» вокруг основного ядра. Никто не может запретить взять DDR-контроллер от компании A, а PCIe — от компании B. Проблема в том, что для каждого такого устройства нужно писать драйвер. И если вендор об этом не позаботился — нанять свою команду и потратить несколько лет на разработку. 

Нельзя вытащить чип одного производителя и поставить в плату другой. Должна быть отдельная сборка операционной системы, которая поддерживает всю специфику периферии процессора. Мы пока не наблюдали глобальных проблем при запуске generic-ядра, но танцев с бубном там было много. И никто не гарантирует, что следующий разработчик не захочет добавить в серверный чип, например, микроконтроллер для включения ядер в определенной последовательности или управления нагрузкой. Если такое случится, танцы с бубном придут уже в серверный сегмент. Хотя сегодня есть более масштабный класс проблем. 

Приложения под ARM нужно глубоко тестировать

Нативной платформой для коммерческого софта является x86. Перед релизом софт тестируется — и только потом выходит в продакшен. Для 80% пользователей достаточно подтвердить работоспособность JVM, V8 и PVM. Но насколько хорошо сами виртуальные машины протестированы под ARM? 

Дело в том, что x86 и ARM отличаются принципиально по своей архитектуре. Если x86 — это CISC-ядро, где каждое поколение пополняется очередной uber-инструкцией, то ARM — это RISC-машина: инструкций мало, они все одной длины и выполняют элементарные действия. Задача JVM — сгенерировать исполняемый бинарный код для целевой архитектуры, который должен отражать бизнес-логику приложения. В x86 этот процесс отточили за 30 лет почти идеально. 

Отличается ли работа JVM на ARM? И если да, то насколько? Это еще предстоит узнать. А ведь помимо JVM есть еще V8, Python и другие машины…  

Проблемы с версиями VM и библиотек под ARM

Один из наших клиентов, который тестировал ARM в Selectel Lab, столкнулся с отсутствием в Arch библиотеки libc, которая поддерживает C++20, тогда как Arch на x86 содержит правильную библиотеку. Да, вопрос решили, но переходом на Ubuntu, где библиотека была. И таких кейсов еще очень много, поэтому нужно проверять, соответствуют ли версии для x86 версии для aarch64. И равносилен ли их заявленный функционал и стабильность работы под пользовательской нагрузкой.

Отдельная история с legacy-кодом на C/C++, который уже не поддерживается, но существует в зависимостях библиотек и ПО. Проблема в том, что исходники не всегда можно найти. А если вы их нашли, то к ним обязательно нет мануалов. Поэтому иногда проще разработать что-то свое, а после — протестировать.

Возможно, есть смысл запускать legacy-библиотеки через эмуляторы. Но здесь пока без результатов. Мы только планируем посмотреть, что будет с производительностью при таком сценарии.

Поведение видеокарт с ARM нестабильно

Большая часть клиентов, решающая задачи AI и ML, использует видеокарты. И на первый взгляд кажется, что ничего не предвещает беды: центральный процессор просто обменивается данными с видеокартой по шине PCIe. Какая разница, какой использовать процессор?

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

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

Если ARM нагрянет завтра, что делать?

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

Для серверного рынка точка невозврата наступит тогда, когда стоимость ARM-платформы сравняется с решением на x86, а после — станет еще дешевле. 

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

Готовы ли наши клиенты к переходу на новую платформу? 

Чтобы ответить на этот вопрос, нужно много тестировать. И хоть все приложения нам проверить не удастся, мы можем опереться на опыт AWS. 

Клиенты AWS уже несколько лет разрабатывают и используют базы данных, мессенджеры и прочие веб-сервисы под ARM. С ними платформа справляется на отлично: если каждый веб-сокет работает в отдельном физическом потоке, приложение не использует сложные команды, а конвейер суперскалярен, то на ARM веб-сервер будет работать быстрее, чем на x86.

Если клиенту нужно запустить на ARM-сервере приложение, протестированное AWS, можно смело хоститься у нас. Но сначала бесплатно, чтобы проверить работоспособность системы, а после — арендовать полноценный инстанс на ARM. 

Если клиенту нужно запустить специфическое приложение, сначала мы его протестируем и сравним тестовые метрики, чтобы понять, оптимально ли разворачивать инстанс на ARM. 

Другая схема взаимодействия с клиентами, которые используют нативный код. В отчетах AWS есть кейсы на базе FFMPEG для транскодирования видео и Tensorflow для ML. А также кейсы использования ARM для развертывания игровых серверов. Если вы попадаете в одну из этих групп, будем взаимодействовать по такой схеме: 

Для клиентов, которые используют нативный код с legacy-библиотеками и непроверенные AWS приложения, мы предлагаем другой сценарий. Если код написан на Go или Rust, а не на C/C++, мы поможем конвертировать его через LLVM — низкоуровневый аналог JVM, а после — перенести на ARM. Если клиент использует C/C++, то можно использовать либо эмуляторы, либо это будет та ниша, где x86 останется навсегда. 

Что мы успели протестировать

Время ARM только начинается, поэтому тестов у нас не очень много, но первые результаты уже есть. Например, мы протестировали 80-ядерный ARM-процессор Ampere Altra. С результатами можно ознакомиться в нашей статьей.

Ниже мы собрали несколько интересных versus-тестов, в которых наши клиенты сравнили ARM-конфигурации с альтернативными на x86. Для тестов мы использовали такую сборку: 

• материнская плата GIGABYTE MP32-AR1-00,
• 16 плашек ОЗУ по 16 ГБ (Micron DDR4 3200 МГц ECC),
• 2 SSD-накопителя Micron_5300 на 480 ГБ,
• NVMe-диск на 1 ТБ M.2 SSD (GIGABYTE GP-AG41TB).

Три GPU подключены для проверки работы PCIe-линий при полной загрузке.

Тестирование веб-приложения

К нам обратился клиент, у которого есть веб-приложение на базе Clickhouse, PostgreSQL и Redis, запущенных в Docker-контейнерах с ограничениями по ОЗУ до 2 ГБ (для Redis – 1 ГБ). 

Тестировали с помощью сервиса k6.io и эмулирование соединения 50 клиентов в течение 6 минут. Получили следующие результаты: 

В однопоточном режиме на клиентских тестах ARM проигрывает, но при хорошем распараллеливании сильно вырывается вперед. Самые неоднозначные результаты в бенчмарках 7z: ARM уступает, если пересчитывать на потоки. И это притом, что у AMD потоки виртуальные. Почему именно так — неизвестно, нужно разбираться. 

→ По результатам тестирования клиент решил повременить с переходом на ARM до тех пор, пока производительность платформы в его задаче не вырастет. 

Тестирование обработки текста

К нам пришел клиент, который занимается «умной» обработкой текста на базе самописного ПО. Он хотел сравнить производительность Xeon Gold 2Gen с нашей ARM-конфигурацией. И предварительно даже описал ожидаемые результаты.

Ожидаемый результат: ARM получил 881 «попугаев», а Intel Xeon Gold 2Gen — 777 на синтетических тестах (13%). 

Фактический результат: 80 ядер ARM обработали текст быстрее, чем 56 ядер и 112 потоков Xeon Gold 2Gen.

Обработчик текста написан на Rust и на Erlang. Пересобрали под ARM легко с помощью LLVM и добились производительности на 13% больше, чем у Xeon Gold 2Gen. Многоядерность ARM-процессоров делает свое дело. Здесь еще сыграл вопрос стоимости. За меньшие деньги клиент может получить более производительное железо.

→ Клиент готов перейти на ARM-платформу, но также хочет протестировать и 128-ядерный процессор.

Выводы и перспективы

Результаты тестов в лаборатории Selectel противоречивы. Для баз данных и веб-серверов ARM Ampere Altra превосходит близкие по производительности конфигурации на Intel и AMD. Но показатели сильно зависят тестируемого приложения.

Нужно помнить, что сегодня x86 — это стандарт для софта. ARM выигрывает за счет своей физической многоядерности и приложений, в которых она важна. Когда речь заходит об однопоточном режиме, ARM сдает в позициях. 

Мы продолжаем наши исследования и верим в скорое пришествие ARM-технологий в серверный сегмент. Нам нужно больше юзкейсов и примеров тестирования на реальной нагрузке. Возможно, получится найти ниши, на которых ARM показывает исключительный рост в производительности. Возможно, есть ряд задач, для которых x86 навсегда останется единственным и неповторимым. Велком к нам — будем тестить вместе!