В чём процессорная сила, брат?
Долгое время, начиная, фактически, с 80-х годов 20-го века и до нынешнего момента, архитектура x86 доминировала на рынке десктопных, а потом и серверных решений и ноутбуков. Для многих жителей планеты Земля слова «компьютер» и «компьютер на базе процессора x86» стали синонимами. Но в последние годы позиции архитектуры x86 перестали выглядеть столь незыблемыми. Виной тому несколько причин: недооценка компанией Intel и в итоге проигрыш мобильного рынка процессоров компании ARM; скукоживание рынка десктопных решений опять-таки по причине роста мобильных устройств; потеря технологического лидерства Intel в разработке самых передовых нанометров, где пальму первенства захватила компания TSMC; недостаточная гибкость бизнес-модели компании Intel, являющейся классической Integrated Device Manufacturing компанией во времена, когда сложность разработки растёт и требует всё большего разделения труда. В итоге, на горизонте у архитектуры x86 появились конкуренты, бросающие ей вызов. В первую очередь это архитектуры Arm и RISC-V. Но несмотря на все сложности текущего положения архитектуры x86, есть важнейший фактор, который ещё долго будет мешать конкурентам скинуть её с трона серверного и десктопного рынков. Этот фактор — колоссальная по объёму программная экосистема, разработанная за десятилетия существования x86. В данной статье хотелось бы кратко осветить вопрос, почему переход с одной процессорной платформы на другую столь болезнен, почему нельзя просто взять и перекомпилировать весь необходимый софт на новую архитектуру и где нас ожидают подвохи и подводные камни.
Немного истории
Начну с краткого исторического экскурса. В отечественном инфополе существует одно достаточное лубочное объяснение того, почему СССР проиграл процессорную гонку США. Звучит оно примерно следующим образом: «в 1960-х годах был взят курс на копирование зарубежных архитектур, что привело к деградации отечественной школы процессоростроения с соответствующими последствиями». Часто этот тезис сопровождается дальнейшими поисками врагов народа, где степень накала таких рассуждений, как правило, обратно пропорциальна уровню понимания вопроса. Мы не будем вдаваться в дебри столь сложной темы, тем более, что за давностью лет многие важные моменты и нюансы остались только в памяти непосредственных участников тех судьбоносных решений, коих уже нет в живых. Но в тех далёких баталиях есть один важный момент, который имеет прямое отношение к нашему вопросу. Благодаря книге Бориса Николаевича Малиновского «История вычислительной техники в лицах» мы имеем возможность прочитать стенограмму заседания декабря 1969-го года в Минрадиопроме, где принималось решение о том, какую систему выбрать в качестве базовой для дальнейших разработок. Из приведённого обсуждения (и предшествующих ему дискуссий) видно, что ключевым фактором, определяющим выбор облика будущей единой архитектуры в СССР, был именно вопрос размера доступной программной экосистемы. По этому поводу в книге есть такая цитата:
Опыт разработки сложных и объемных операционных систем показал, что на их создание требуется труда даже больше (тысячи человеко-лет), чем на разработку собственно технических средств
Таким образом, уже в конце 60-х годов 20-го века, размер программной экосистемы был доминирующим фактором в вопросе выбора аппаратных решений. Недаром, если судить по стенограмме, то фактически, корифеями отечественной микроэлектрониики и профильными чиновниками обсуждался выбор между всего двумя вариантами — нелегальное копирование системы IBM-360 на базе задела работ, созданного коллегами из ГДР или лицензирование у английской компании ICL ЭВМ «Система-4», являющейся в свою очередь легальным клоном той же IBM-360 (в итоге был выбран первый вариант). Т.е. в обоих случаях была цель переиспользовать уже разработанное для IBM-360 программное обеспечение в том или ином виде. Что же говорить о нынешней ситуации, когда десятки миллионов программистов ежегодно на протяжении уже более 30 лет разрабатывают ПО, предназначенное для работы на платформе x86.
Но почему нельзя просто взять и перенести уже разработанное ПО на новую архитектуру? Ведь казалось бы, бОльшая часть разработки сейчас ведётся на языках высокого уровня, которые в общем случае, должны быть архитектурно независимы. Почему вендоры ПО не горят желанием перекомпилировать свой софт на новые платформы? В чём сложность? Давайте разбираться.
Языки программирования
Начнём с вопроса того, какой стек языков программирования вы используете для создания своего программного продукта. Рождение новой архитектуры сопровождается созданием базового набора системного ПО — компиляторов, библиотек, операционных систем и т.д. Но всё это в первую очередь — для C/C++. Далее идёт разработка ПО для поддержки других популярных языков программирования. Но ясно, что если у вас в стеке используется что-то не столь распространнённое, то вы не сможете просто физически свой софт скомпилировать. А ждать момента, когда такая поддержка появится, можно годы. Например, для той же Java (одного из важнейших ЯП) поддержка архитектуры RISC-V в OpenJDK появилась только в этом году. Что уж говорить о чём-то более экзотическом, условных Haskell или D, их поддержки можно вообще не дождаться. Поэтому, проблема отсутствия должной поддержки широкой номенклатуры используемых языков программирования и сопутствующего им системного ПО является важнейшим фактором, препятствующим распространению новой архитектуры.
ОС Windows
Есть второй, очень важный момент — это операционная система, на которой работает ваше ПО. В том случае, если это Windows, то ситация становится драматической. Ведь недаром экосистему x86 часто называют Wintel — ОС Windows и архитектура x86 настолько шли друг с другом рука об руку, что разработка под Windows фактически означает жёсткую привязку к x86. Ведь фактически, экосистема MS Windows доступна только для архитектуры x86. Да, есть версии Windows под Arm, но:
Только для определённых устройств (а поддержки интересующих вас, например, на базе условного Байкал-М, там не будет)
Кроме самой ОС нужна ещё инфраструктура библиотек и прочего ПО, которое для ARM портировано в минимальном объёме
Для остальных архитектур (той же RISC-V) ОС Windows нет физически, и всё, что вам остаётся — это портирование своего ПО на Linux. А эта задача по сложности и трудозатратам может быть сопоставима с разработкой ПО с нуля. В определённых случаях можно попробовать обойтись утилитой Wine, но мой опыт работы с данным программным продуктом показывает, что это костыль и более-менее вменяемо он работает только для несложного ПО и игр. А для более серьёзных программных продуктов он просто неприменим.
Именно поэтому, кстати, переход на какую-либо отечественную платформу должен в первую очередь сопровождаться стимулированием разработчиков портировать своё ПО на Linux, вплоть до запрета попадания в различные «реестры отечественного ПО» в Windows-версий приложений. Особенно это актуально в нынешних условиях, когда компания Microsoft официально покинула российский рынок.
ОС Linux
Но допустим, ПО разработано (или портировано) под Linux. Написано на C/C++, т.е. вы изначально имеете доступ к достаточно обширному стеку системного ПО, позволяющего вести разработку под новую архитектуру. Всё хорошо? Нажимаем кнопку «скомпилировать проект» и наслаждаемся результатом? К сожалению, нет, нас ждут потенциально следующие проблемы:
Ваше ПО содержит архитектурно специфичные части: ассемблерные вставки, интринсики, какие-то закладки на специфику адресных пространств и т.д. Особенно я хотел бы отметить проблему memory ordering — неявные закладки на особенности Интеловской реализации могут приводить к крайне сложным в поиске ошибкам.
В целом, я бы сказал, что наличие архитектурно-специфичного кода — это не столь частая проблема, но с ростом качества и сложности софта она тоже растёт и может становиться доминирующей, если софт серьёзно соптимизирован под x86. Собственно, все такие вещи надо портировать.
Переход на новый компилятор. Даже если вы собирали свой проект условным gcc, то простая замена x86 версии на Arm, скорее всего, приведёт к появлению ошибок компиляции, с которыми придётся разбираться. Это происходит из-за того, что два компилятора даже под одну архитектуру, но разных версий (например, gcc 9.3.0 и gcc 10.3.0) имеют отличия, и то, что без ошибок скомпилируется на одной версии, не будет компилироавться на другой. У компиляторов под другую архитектуру может быть своя специфика, закладки на какие-то undefined behavior и поэтому сгенерированный код может вести себя немного по разному. Вот, например, обзорная статья от Microsoft о нюансах перекомпиляции кода под архитектуру Arm. На моей памяти, ни один переход на новую версию компилятора не прошёл «бесшовно» — всегда приходилось править какие-то ошибки.
Данная проблема достаточно массовая, но на мой взгляд, не шибко сложная. Опытный разработчик, хорошо знающий свой проект, скорее всего способен достаточно быстро поправить все возникшие проблемы.
Недостаток доступных библиотек. Т.е. вы собираете проект, а он линкует библиотеку, которая не портирована на новую архитектур (или не портирована нужная версия). В таком случае придётся заниматься ещё и портированием недостающего софта. Причём по цепочке можно упереться по итогу в такое legacy, что масштаб работ будет сопоставим с разработкой определённых библиотек с нуля, хотя в этом ранее не было никакой необходимости.
По моему опыту, это массовая и достаточно трудоёмкая проблема
Проприетарный софт. Тут всё понятно. Если вы в том или ином виде завязаны на проприетарный софт, то либо вам придётся от него отказываться и искать заменители (что может быть крайне затратно), либо ждать, когда владельцы портируют его на нужную вам платформу.
Данная проблема усугубляется тем, что поставщикам конечных решений, использующих ПО от разных производителей и занимающихся его интеграцией, необходимо, чтобы все элементы их конечного решения были портированы на нужную платформу. Если же нет хотя бы одной части, то с решением на базе новой архитектуры возникает проблема, и приходится ставить старый привычный x86, на котором «всё работает». И как правило, чем более сложные решения , тем больше всякого проприетарного софта, который существует только для x86 и для которого нет адекватной замены. Возникает проблема курицы и яйца — владельцы софта не видят смысла тратить кучу ресурсов на портирование сложного ПО на новое железо, если его продажи минимальны, а продажи железа с новой архитектурой минимальны, потому что под него нет ПО. Круг замыкается.
Поддержка кода
Поддержка любой новой архитектуры в цикле разработки требует дополнительных ресурсов. Это не только разовые затраты на портирование, но и постоянные на регулярные сборки, тестирования, отладки и т.д. Всё это усложняет процесс разработки и требует дополнительных расходов, которые, без весомых причин, никто нести не хочет.
Производительность
Бытует мнение, что переходу на новую архитектуру также мешает большое снижение производительности при перекомпиляции кода, т.к., дескать, «всё ПО оптимизировано под x86». И поэтому требуются большие затраты на оптимизацию кода под новую архитектуру.
Тут хочется отделить зёрна от плёвел. Вообще говоря, сам по себе код на языке программирования высокого уровня не имеет привязки к конкретной архитектуре и обладает примерно равным потенциалом по скорости для развитых RISC/CISC архитектур, коими являются x86, Arm, Risc-V (это не совсем так, например, для VLIW-архитектур, но этот вопрос широко обсуждался в предыдущих статьях). Поэтому, если ваш проект компилировался под x86 с помощью gcc/clang, то с высокой вероятностью при перекомпиляции на Arm, скорость работы ПО будет идентичной по модулю различий производительности аппаратуры. Но есть, конечно же, нюансы. Разница может возникнуть в следующих случаях:
Вы использовали компилятор icc. Это проприетарный компилятор от Intel, позволяющий выжать максимальную производительность из интеловских процессоров. На целочисленных задачах разницы с gcc практически не будет скорее всего, но на HPC нагрузках компилятор icc вполне может добавить 10–20% к скорости работы программы.
Вы разрабатываете под Risc-V на C/C++. Открытые компиляторы (gcc, clang+llvm) в данный момент генерируют примерно равный по производительности код для архитектур x86 и ARM. В случае же архитектуры RISC-V бэкенд ещё не столь «взрослый» и есть немалая вероятность, что в определённых случаях можно наткнуться на неоптимальности и, как следствие, потерять от нескольких единиц до нескольких десятков процентов производительности в самых худших случаях.
Вы используете в разработке что-то отличное от C/C++. В таком случае, ситуация в общем случае будет следующей — производительность под Arm будет приближаться к x86, местами сравниваясь с ней, Risc-V сейчас будет проигрывать, но гандикап от конкурентов будет быстро уменьшаться в ближайшие годы по мере взросления архитектуры.
Вы используете оптимизированные ассемблерные вставки. В таком случае, вам придётся потратить время на их портирование на новую архитектуру, и вполне возможно, что первые варианты будут уступать по эффективности своим x86-аналогам.
Вы используете оптимизированные библиотеки, которые есть только под x86. В таком случае не факт, что у вас получится найти аналоги под новую архитектуру, и придётся использовать менее быстрые версии библиотек.
Ваш код жёстко заточен на определённую конфигурацию процессора (например, на размеры и иерархию кэшей). Но в таком случае переезд даже на другой x86-процессор может привести к существенным деградациям.
Таким образом, речь скорее должна идти об оптимизации и развитии соответствующего стека системного ПО: компиляторов, виртуальных машин и различных библиотек, а не непосредственно об оптимизации кода приложений самих по себе. Но тем не менее, риски дополнительных объёмных работ по анализу и повышению производительности, также присутствуют.
В качестве резюме
При разработке любого железа, надо всегда помнить одну простую, но исключительно важную истину:
