X86 что это

Содержание

ARM против x86: В чем разница между двумя архитектурами процессоров?
Почему пишут x86, а означает это x32?
В чём процессорная сила, брат?

Спрос на ARM в итоге вырастет. Для индустрии это не просто важный шаг, а архиважный. Линус Торвальдс говорил, что пока рабочие станции не станут работать на ARM — на рынке серверов будут использовать x86.

ARM против x86: В чем разница между двумя архитектурами процессоров?

Вы наверняка знаете, что мир процессоров разбит на два лагеря. Если вы смотрите это видео со смартфона, то для вас работает процессор на архитектуре ARM, а если с ноутбука, для вас трудится чип на архитектуре x86.

А теперь еще и Apple объявила, что переводит свои Mac на собственные процессоры Apple Silicon на архитектуре ARM. Мы уже рассказывали, почему так происходит. А сегодня давайте подробно разберемся, в чем принципиальные отличия x86 и ARM. И зачем Apple в это все вписалась?

Итак, большинство мобильных устройств, iPhone и Android’ы работают на ARM’е. Qualcomm, HUAWEI Kirin, Samsung Exynos и Apple A13/A14 Bionic — это все ARM-процессоры.

А вот на компьютере не так — там доминирует x86 под крылом Intel и AMD. Именно поэтому на телефоне мы не можем запустить Word с компьютера.

x86 — так называется по последним цифрам семейства классических процессоров Intel 70-80х годов.

Чем же они отличаются?

Есть два ключевых отличия.

Первое — это набор инструкций, то есть язык который понимает процессор

x86 процессоры используют сложный набор инструкций, который называется CISC — Complex Instruction Set Computing.

ARM процессоры наоборот используют упрощенный набор инструкций — RISC — Reduced Instruction Set Computing.

Кстати ARM расшифровывается как Продвинутые RISC машины — Advanced RISC Machines.

Наборы инструкций ещё принято назвать архитектурой или ISA — Instruction Set Architecture.

Второе отличие — это микроархитектура. Что это такое?

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

x86 — CISC
ARM — RISC

Но как так произошло, что процессоры стали говорить на разных языках?

История CISC

Памятка программиста, 1960-е годы. Цифровой (машинный) код «Минск-22».

Всё началось в 1960-х. Поначалу программисты работали с машинным кодом, то есть реально писали нолики и единички. Это быстро всех достало и появился Assembler. Низкоуровневый язык программирования, который позволял писать простые команды типа сложить, скопировать и прочее.

Но программировать на Assembler’е тоже было несладко. Потому как приходилось буквально “за ручку” поэтапно описывать процессору каждое его действие.

Поэтому, если бы вы ужинали с процессором, и попросили передать его вам соль, это выглядело бы так:

Эй процессор, посмотри в центр стола.
Видишь соль? Возьми её.
Теперь посмотри на меня.
Отдай мне соль. — Ага, спасибо!
А теперь снова возьми у меня соль.
Поставь её откуда взял
Спасибо большое! Продолжай свои дела.
Кхм… Процессор, видишь перец?
И так далее.

Этот подход стал настоящим спасением как для разработчиков, так и для бизнеса. Захотел клиент новую инструкцию — не проблема, были бы деньги — мы сделаем. А деньги у клиентов были.

Недостатки CISC

Но был ли такой подход оптимальным. С точки зрения разработчиков — да. Но вот микроархитектура страдала.

Представьте, вы купили квартиру и теперь вам нужно обставить её мебелью. Площади мало, каждый квадратный метр на счету. И вот представьте, если бы CISC-процессор обставил мебелью вам гостиную, он бы с одной стороны позаботился о комфорте каждого потенциального гостя и выделил бы для него своё персональное место.

С другой стороны, он бы не щадил бюджет. Диван для одного человека, пуф для другого, кушетка для третьего, трон из Игры Престолов для вашей Дейенерис. В этом случае площадь комнаты бы очень быстро закончилась. Чтобы разместить всех вам бы пришлось увеличивать бюджет и расширять зал. Это не рационально.

Но самое главное, CISC-архитектура существует очень давно и те инструкции, которые были написаны в 60-х годах сейчас уже вообще не актуальны. Поэтому часть мебели, а точнее исполнительных блоков, просто не будут использоваться. Но многие из них там остаются. Поэтому появился RISC…

Преимущества RISC

С одной стороны писать на Assembler’е под RISC процессоры не очень-то удобно. Если в лоб сравнивать код, написанный под CISC и RISC процессоры, очевидно преимущество первого.

Так выглядит код одной и той же операции для x86 и ARM.

x86

MOV AX, 15; AH = 00, AL = 0Fh
AAA; AH = 01, AL = 05
RET

MOV R3, #10
AND R2, R0, #0xF
CMP R2, R3
IT LT
BLT elsebranch
ADD R2. #6
ADD R1. #1
elsebranch:
END

Представьте, что вы проектируете процессор. Расположение блоков на х86 выглядело бы так.

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

Ему не нужны блоки, созданные для функций, написанных 50 лет назад.

По сути, тут блоки только для самых востребованных команд. Зато таких блоков много. А это значит, что можно одновременно выполнять больше базовых команд. А раритетные не занимают место.

Еще один бонус сокращенного набора RISC: меньше места на чипе занимает блок по декодированию команд. Да, для этого тоже нужно место. Архитектура RISC проще и удобнее, загибайте пальцы:

проще работа с памятью,
более богатая регистровая архитектура,
легче делать 32/64/128 разряды,
легче оптимизировать,
меньше энергопотребление,
проще масштабировать и делать отладку.

Поэтому наши смартфоны, которые работают на ARM процессорах с архитектурой RISC, долго живут, не требуют активного охлаждения и такие быстрые.

Лицензирование

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

Даже Apple приложила руку к развитию ARM. Вместе с Acorn Computers и VLSI Technology. Apple присоединился к альянсу из-за их грядущего устройства — Newton. Устройства, главной функцией которого было распознавание текста.

Даже вы можете начать производить свои процессоры, купив лицензию. А вот производить процессоры на x86 не может никто кроме синей и красной компании. А это значит что? Правильно, меньше конкуренции, медленнее развитие.

Как же так произошло?

Ну окей. Допустим ARM прекрасно справляется со смартфонами и планшетами, но как насчет компьютеров и серверов, где вся поляна исторически поделена? И зачем Apple вообще ломанулась туда со своим Apple Silicon.

Что сейчас?

Допустим мы решили, что архитектура ARM более эффективная и универсальная. Что теперь? x86 похоронен?

На самом деле, в Intel и AMD не дураки сидят. И сейчас под капотом современные CISC-процессоры очень похожи на RISC. Постепенно разработчики CISC-процессоров все-таки пришли к этому и начали делать гибридные процессоры, но старый хвост так просто нельзя сбросить.

Но уже достаточно давно процессоры Intel и AMD разбивают входные инструкции на более мелкие микро инструкции (micro-ops), которые в дальнейшем — сейчас вы удивитесь — исполняются RISC ядром.

Да-да, ребята! Те самые 4-8 ядер в вашем ПК — это тоже RISC-ядра!

Надеюсь, тут вы окончательно запутались. Но суть в том, что разница между RISC и CISC-дизайнами уже сейчас минимальна.

А что остается важным — так это микроархитектура. То есть то, насколько эффективно все организовано на самом камне.

Ну вы уже наверное знаете, что Современные iPad практически не уступают 15-дюймовым MacBook Pro с процессорами Core i7 и Core i9.

А что с компьютерами?

Недавно компания Ampere представила свой 80-ядерный ARM процессор. По заявлению производителя в тестах процессор Ampere показывает результат на 4% лучше, чем самый быстрый процессор EPYC от AMD и потребляет на 14% меньше энергии.

Компания Ampere лезет в сегменты Cloud и Workstation, и показывает там отличные цифры. Самый быстрый суперкомпьютер в мире сегодня работает на ARM ISA. С обратной стороны, Intel пытается все таки влезть в сегмент low power и для этого выпускает новый интересный процессор на микроархитектуре lakefield.

Hello World на Ассемблере (x86)

Пока у ноутбуков и процессоров от Intel есть одно неоспоримое достоинство — (охлаждение и) единство архитектуры. Пока на рынке ARM-процессоров существуют Qualcomm, Samsung, MediaTek, в мире x86 творится монополия и разработчикам сильно легче делать софт и игры под “взрослые” процессоры.

И Apple та компания, которая способна мотивировать достаточное количество разработчиков пилить под свой ARM. Но суть этого перехода скорее не в противостоянии CISC и RISC. Поскольку оба подхода сближаются, акцент смещается на микроархитектуру, которую делает Apple для своих мобильных устройств. И судя по всему микроархитектура у них крута.

И они хотели бы ее использовать в своих компьютерах.

И если бы Intel лицензировал x86 за деньги другим людям, то вероятно Apple просто адаптировали свою текущую микроархитектуру под x86. Но так как они не могут этого сделать, они решили просто перейти на ARM. Проблема для нас с микроархитектурой в том, что она коммерческая тайна. И мы про нее ничего не знаем.

Итоги

Спрос на ARM в итоге вырастет. Для индустрии это не просто важный шаг, а архиважный. Линус Торвальдс говорил, что пока рабочие станции не станут работать на ARM — на рынке серверов будут использовать x86.

И вот это случилось — в перспективе это миллионы долларов, вложенных в серверные решения. Что, конечно, хорошо и для потребителей. Нас ждет светлое будущее и Apple, действительно, совершила революцию!

Редактор материала: Антон Евстратенко. Этот материал помогли подготовить наши зрители Никита Куликов и Григорий Чирков. Спасибо ребята!

Блог компании Droider.Ru
Программирование
Смартфоны
Ноутбуки
Процессоры

Почему пишут x86, а означает это x32?

Потому, что когда появились камни 64 битные, спрос на 32 битные упал и маркетологи, чтобы поднять продажи обозвали их 86, дабы хомячки думали — если больше, значит лучше, хотя 86 — это всего-лишь архитектура процессора (система команд, если хотите) , далее см. Ответ TrollKiller.

Остальные ответы

Дело в том, что x86 — это архитектура микропроцессора и аппаратная платформа, которая применима и тридцати двум битным и к шестидесяти четырех битным программам. Название x86 получено от первого наименования первого процессора intel i8086 и ряда последующих, в которых в конце всегда приписывалась 86. Через какое-то время цифровые обозначения новых процессоров стали заменяться именами, так публика узнала о Pentium и Celeron, но платформа x86 не изменилась до наших дней.

Значения два, а обозначения три? x82, x32 и x64 — как правильно писать?

И если x86 это архитектура процессора, то x32 и x64 это его разрядность – адресное пространство, а также количество информации, которую процессор в силах обработать за один такт.

Когда же пишут о совместимости программ указывая разрядность x86, подразумевая 32-битную платформу, это неправильно и только вводит в заблуждение. Правильно указывать х86_32bit или х86_64bit. Либо сокращенно интуитивно понятные x32 или x64.

Архитектура x86. Уверены, что знаете свой домашний компьютер?

Так что можно подытожить: сейчас x86 указывают по старинке (даже Майкрософт этим грешит) , когда эта платформа была в единственном числе и 64-битных еще никто не знал. При появлении платформы x64 её стали указывать как есть, а прежняя 32-битная так и осталась в большинстве случаев как x86. И сейчас это не актуально, ошибочно и сбивает с толку тех, кто не понимает суть. А вы её теперь понимаете. 🙂

x32 или x64? Что выбрать? Что лучше?

Очень часто возникает вопрос, выбрать операционную систему x32 или x64? То есть тридцати двух битную или шестидесяти четырех битную?
Это вопрос риторический, теоретический и спорный. Очевидно, что x64 лучше, но не всегда и не в случае, если вы пользуетесь Windows. Нет, любая Windows x64 работает чуть шустрее чем Windows x32, но только если есть все программы и все драйвера под 64-битную систему. Очень часто, если компьютер современный, все системные драйвера к комплектующим у него обычно есть.

Но проблема кроется тогда в программах и особенно видео и аудио кодеках. Обязательно чего-то да не будет. И если тридцати двух битные программы могут работать в системе x64, то драйвера и кодеки к ней обязательно нужны тоже x64. Год от года эта проблема исчезает, но до сих пор она не развеяна полностью.

С системами x32 таких проблем нет и для дома лучше выбирать именно такую.

.Знаток (328) 5 лет назад

Выбор разрядности более зависит от количества оперативной памяти и, если речь идёт о Windows 7 или более устаревшей, чуть менее от количества ядер ЦП. 32-разрядные операционные системы принципиально не обнаруживают более 3.5 ГБ оперативной памяти, однако 64-разрядные потребляют оперативной памяти значительно больше. Таким образом если оперативной памяти 2 ГБ, то установка 64-битной системы на такую конфигурацию крайне не рекомендуется, так же точно как и не рекомендуется установка 32-битной на конфигурацию с 8 ГБ оперативной памяти. Иначе говоря, если оперативной памяти более 3 ГБ, то безусловно лучше будет установить 64 бита.

Также 32-разрядные версии Windows 7 не способны раскрывать полную частоту ЦП с количеством ядер более двух, но в более новых системах Windows эта проблема решена.

1. x32 — вообще не существует, если так пишут, то по незнанию и допускаю ошибку.
2. x64 — это тип платформы. И да, еще она говорит о битности адресации процессора и для этой платформы равна 64 битам. То есть для обработки любой команды процесор должен обратиться к памяти по «адресу» и чем больше возможная битность адреса, тем больше памяти может увидеть процессор.
3. x86 — тоже тип платформы, для который разрядность адресации равна 32 битам.

Конкретно отвечая на вопрос — х64 отличается от х86 версии (будь то процессор, операционная система или приложение) возможностью работы с большим количеством памяти (что приятно к примеру в работе с приложениями требующими большие объемы оперативной памяти, как к примеру графические редакторы и редакторы музыки/видео) .

И еще один момент — работает иерархичная структура, то есть ля того, чтобы к примеру запустить 64-битный WinRAR нужно, чтобы в первую очередь процессор был x64, была установлена x64 операционная система и соответственно 64-битный Винрар.

От имени семейства процессоров Intel — 8086, 80286, 80386, 80486 .
Просто первые цифры для экономии краски в документации :-)) видимо, заменили на букву икс.. .
А были эти процессоры именно 32-х битными.
Ну вот такая традиция у америкосов.

Архитектура х86 означает разрядность в 32 бит.
Rifkat ValievГуру (3651) 10 лет назад
Спасибо, этот ответ проглядывается в вопросе.

Еще совсем не так давно, практически все компьютеры работали под 32-битной операционной системой. Чаще всего это была Windows XP, но в скором времени в обиход вошла Windows 7. Но большей частью пользователи ставили на свои машины, тоже 32-битную версию. Хотя как Windows XP, так и Windows 7, были доступны и в 64-битном исполнении. Но использовали их только люди занимающиеся видеомонтажом, то есть те, что были вынуждены запускать программы, требующие дополнительных ресурсов. 86 бит-копия 32 бит, но просит меньше требовании

В чём процессорная сила, брат?

Долгое время, начиная, фактически, с 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-процессор может привести к существенным деградациям.

Таким образом, речь скорее должна идти об оптимизации и развитии соответствующего стека системного ПО: компиляторов, виртуальных машин и различных библиотек, а не непосредственно об оптимизации кода приложений самих по себе. Но тем не менее, риски дополнительных объёмных работ по анализу и повышению производительности, также присутствуют.

В качестве резюме

При разработке любого железа, надо всегда помнить одну простую, но исключительно важную истину: