Долгое время, начиная, фактически, с 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-процессор может привести к существенным деградациям.
Таким образом, речь скорее должна идти об оптимизации и развитии соответствующего стека системного ПО: компиляторов, виртуальных машин и различных библиотек, а не непосредственно об оптимизации кода приложений самих по себе. Но тем не менее, риски дополнительных объёмных работ по анализу и повышению производительности, также присутствуют.
В качестве резюме
При разработке любого железа, надо всегда помнить одну простую, но исключительно важную истину:
Комментарии (27)
Amiveo
31.07.2022 07:43+3Что касается серверных решений, то доминирование в высоконагруженных системах началось в 2010-х годах. Связано это было в первую очередь со стоимостью закупки и поддержки, которая для х86 стала в разы меньше, чем PA-RISK (HP), Sparc (Sun) и PowerPC (IBM). Доходило до того, что дешевле было купить новый сервер на базе х86, чем поддерживать 3-летний Sun sparc аналогичной производительности. Собственно, поэтому вендоры начали массово переводить свой парк на х86.
Armmaster Автор
31.07.2022 12:21Я в статье указал, что доминирование x86 в серверах началось "затем", специально не конкретизируя дату, ибо это дискуссионный вопрос. Главное, я думаю никого не будет сомнений, что на текущий момент архитектура x86 - лидер серверного сегмента в части CPU.
Amiveo
31.07.2022 17:06+2Я не знаю, какая архитектура сейчас лидирует, и по каким критериям. Я утверждаю, что доминирование началось именно тогда, когда производительность серверных систем на х86 достигла RISC-систем, а TCO при этом начало стремительно падать. В нашем мире всё упирается исключительно в бабки.
Hardcoin
31.07.2022 19:50-2Не похоже. Когда люди убивают друг друга, каждый ли из них так много заработает на этом?
byman
31.07.2022 10:37+1Если софт так важен, то не видно смысла и в RISC-V (да и в любой новой процессорной архитектуре). Стоит ли менять шило на мыло только ради того чтобы не платить немного ARM, а потратить куда больше денег на софт для новой архитектуры?
select26
31.07.2022 10:56+3Конечно стоит переписать основное ПО и тяжелые алгоритмы на C. Это даст кратный в разы выхлоп с точки зрения CPU costs. Т.е., например, вместо покупки новых 10 серверов вы сможете обойтись существующими 10. Но вложиться нужно будет не в железо, а в ПО.
Но это очень непопулярная точка зрения. К сожелению.
Почему к сожалению?
Потому что стоимость разработки ПО "размазываеся" на число исталляций. И условная оптимизация на 10% при милиллионном траже позволит сэкономить 100К условных CPU.
Но это, как я уже говорил, тренд немодный. Ибо важнее "скорость выхода на рынок. остальное - допилим потом".
Armmaster Автор
31.07.2022 12:32Софт важен (про то и статья), но это не единственный фактор, конечно же. Есть сегменты, где зависимость по софту не столь критическая. Например, всякие мелкие процессоры/контроллеры, где поставщик конечного решения вполне может иметь почти всё в своих руках и ему не так сложно перейти на новую архитектуру. Именно поэтому RISC-V сейчас используется в основном во всяких микроконтроллерных исполнениях (ну и конечно ещё потому, что для создания более сложных CPU требуется больше времени и ресурсов и уже определённая аппаратная экосистема).
Также есть определённые ниши, где привязка к архитектуре тоже не столь сильная, и можно портировав небольшой стек ПО уже иметь возможность предлагать там конкурентно способные решения. История развития того же Arm в последнее время - это как раз про это. Они пытаются начать экспансию с захвата именно таких сегментов - файловые хранилища, веб-сервисы и тому подобное. А вот заменить x86-десктоп с MS Word и MS Excel они пока не стремятся.
Alexey2005
31.07.2022 14:12+9Я понимаю, почему за ARM так топят вендоры — для них это просто манна небесная. Но вот почему ARM поддерживают и пропагандируют ещё и пользователи — этого я понять не могу.
Что получает рядовой пользователь от ARM, кроме лишения остатков свободы? Ведь ARM — это конструктор вендорно огороженных SoC'ов. И покупая устройство на ARM, вы купите вендорно огороженный SoC, на который поставятся только те ОС и только тех версий, которые поддерживаются вендором.
x86 — единственная на данный момент архитектура, на которой можно запустить абсолютно всё — от древней MS DOS до ОС Android, причём любых версий. Можете назвать хоть одно устройство на ARM, на которое можно было бы поставить по выбору скажем Android 2.3, Android 4.2 и Android 12?
ARM по сравнению с x86 — просто убогий загон, где все должны кланяться в ножки вендору.
zorn-v
31.07.2022 15:56просто убогий загон, где все должны кланяться в ножки вендору.
Ну все таки не вендору, а тому кто сканпелирует линукс под проц и (САМОЕ ГЛАВНОЕ !) железо прилагающееся к нему.
Хоть это и не сильно сложно, но зачем кому то это делать если не "просто захотелось" ?
А под х86/64 все есть.
Нападок не надо, ибо это разумно "не заниматься фигнёй". Возьмем среднестатистического (не из silicon valley) "шарющего студента". Об ARM его интузиазм разобьется еще в зародыше )
PS. Когда состоял в тусовке Siemens SX1 одна мысль меня постоянно настигала - а мне вообще потом пригодится это знание ARM ASM в жизни ? )
Кстати пока не пригодилось )
edo1h
31.07.2022 16:08-1И покупая устройство на ARM, вы купите вендорно огороженный SoC, на который поставятся только те ОС и только тех версий, которые поддерживаются вендором.
разве? вот у меня на столе стоит raspberry pi, на которой крутится собственноручно собранный с помощью buildroot образ linux. всякие *bsd тоже не проблема поставить.
то же самое и с виртуалками на arm в aws, например.
F0iL
31.07.2022 20:42+1RPi в этом плане просто приятно выделяется. Настолько причтно, что когда производитель их SoC решил открыть драйвера, все очень удивились и торжественно признали RPi первым ARM-одноплатником полнофункциональным без драйверов-блобов.
edo1h
31.07.2022 23:29ну если на то пошло, то драйвера-блобы и для x86 есть.
arm-железок, на которых можно загрузить неподписанное ядро linux сейчас много.
да, в основном это мелкие железки: rpi и клоны, wifi-роутеры. но тот же байкал ЕМНИП грузит неподписанное ядро, а драйвера разработчики байкала пропихивают в апстрим. десктопы на байкале уже показывали.
кстати, на apple m1 же тоже запустили linux; не слежу за проектом, но раз у них получилось, подпись кода необязательна. да, там не всё гладко с драйверами, но говорить о вендор-локе не приходится.
Viknet
01.08.2022 13:02+1У M1 совсем своя система обеспечения безопасности и схема загрузки, не имеющая ничего общего с большей частью ARM-систем. И запуск сторонних ОС там сделан целенаправленно.
А вот с драйверами всё плохо почти на всех ARM-платформах. Даже в рамках одной линейки SoC одного производителя, самые базовые части, вроде контроллера прерываний, постоянно меняются, и кто-то должен постоянно заниматься реверс-инженерингом, чтобы просто иметь возможность стартануть ядро. Не говоря уже о проприетарном управлении питанием, сетевых контроллерах, GPU...
vitalyvitaly
31.07.2022 23:11абсолютно всё — от древней MS DOS
По факту - все старые версии Windows на относительно современном железе давным-давно отрезаны не только имплицитно (отсутствием драйверов), но и по факту применяются активные меры, чтобы этого сделать не смогли. Как вы собираетесь запустить на голом железе, например, Windows 95 или NT 3.51? Вы можете запустить определенные версии DOS, но скорее всего это будет FreeDos - от классической DOS (я ставил на размеченную флэшку версию 3.3!) толку будет очень-очень мало. Плюс неминуемо вылезут разные прелести вроде того, что современные системы уже очень плохо переваривают старинные менеджеры памяти вроде EMM386, а часть видеорежимов VGA и даже EGA намертво вырезана так, что на голом железе не заработают даже обычные игрушки из 1990 года. Про звук с материнской платы под DOS-режимом на голом железе, конечно, можно сразу забыть, этому уже лет двадцать как.
victor_1212
31.07.2022 16:37+2> многие важные моменты и нюансы остались только в памяти непосредственных участников тех судьбоносных решений, коих уже нет в живых
непосредственным участником не был, но где-то около контакты были, для тех кому интересно небольшие субъективные замечания без претензий на истину в конечной инстанции:
не стоит переоценивать техническую рациональность принятых в то время решений, начиная с 50х общая тенденция в промышленности была на создание удельных вотчин, и всяческая о них забота, при Сталине вероятно это сдерживалось страхом, позже при Хрущеве и Брежневе стало обычным делом, особенно в оборонке, где закрытость информации способствовала,
главные и генеральные конструктора имели супер высокий статус и его поддерживали как могли, правила игры при этом не слишком соблюдались, начал работать отрицательный отбор, достаточно известна история главного конструктора Кисунько (МРП), они довольно успешно занимались ПРО, типа впервые в мире сделали реальный перехват, но в те дальние времена когда о нем практически никто не знал, слышал подробности от людей с ним работавших, по их выражению "съели живьем", не хочу вдаваться в детали, просто характеризует обстановку в одном из наиболее продвинутых министерств, это к тому кто и как принимал решения в том числе на упомянутом заседании в МРП (декабрь 1969) ,
думаю, что в начале 70х по вычислительной технике уровни еще были достаточно близки, кое-где вообше дела шли неплохо, в первую очередь институт Лебедева, но болото уже затягивало, решения на самом высоком уровне принимались с учетом интересов удельных князей и бояр которые их готовили, что постепенно затормозило развитие, хотя конечно слова говорились всегда правильные, но дисциплина выполнения решений постепенно ушла в прошлое, примерно так, типа дополнение к статье для понимания обстановки того времени
victor_1212
31.07.2022 22:01+1ps
т.е. практически все стратегические решения того времени не были объективными техническими в точном смысле, всегда за ними были личные и групповые интересы тех или иных главных конструкторов, директоров институтов, министров и пр. начальников (поддерживающих друг друга по интересам), imho не менее чем 50/50, между техникой и политикой по типу византийской, это слегка шокировало пока не привык когда-то очень давно
napa3um
В статье - какое-то субъективное и, чессгря, наивное мнение инженера-программиста, а скорее даже навязываемое программистам мнение, раздувающее значимость их технических навыков и скрывающее под ковром основную причину - экономическую. Пример Эпла, которая дважды меняла архитектуру своей аппаратуры с сохранением преемственности всей своей софтварной экосистемы, показывает, что дело не совсем в технологиях, а, скорее, в издержках на их внедрение, которые не просто в деньгах выражаются, а во всех интересах всех задействованных участников завязанного на соответствующих технологиях рынка. И "лубочное" объяснение сворачивания советских разработок - вполне себе объективное, это действительно был в каком-то смысле "подкуп" имеющих отношение к отечественной отрасли ИТ персоналий и институтов более крупными капиталами, стоящими за IBM и всеми её партнёрами (и просто сверхвыгодными контрактами, и даже в прямом смысле "откатами"). Это называется навязыванием технологического отставания, или в терминах конкретной реализации этой стратегии - вендорлоком. Ведь зачем развивать собственную независимую технологию, если можно дёшево получить уже готовую, пусть и такую, на развитие которой ты повлиять не можешь (а впоследствии - и на её ценообразование). Подозреваю, что в ближайшее время из Китая в мировую среду выплеснется кучка процессорных архитектур, показывая, что монополия x86 была в большей степени экономической проблемой, ежели технической :).
SabMakc
Да, дело в издержках. Всегда все можно объяснить издержками.
И пример Apple не показателен. Они не избавились от x86, а написали эмулятор x86. Причем очень хорошо работающий эмулятор. Но не идеально. И множество сайтов вида "что запустится на ARM-маке" тому доказательство. Спустя 2 года неработающего ПО все еще достаточно много. И очень большая куча ПО работает только через эмулятор x86.
И это при том, что Apple экосистему своего ПО очень хорошо контролирует. И не забываем, что Apple - компания очень крупная, с очень большой базой пользователей, причем крайне преданных пользователей.
Что, впрочем, не меняет того факта, что их чипы M1 получились крайне выдающимися. И да, это очень серьезная заявка на конкуренцию с x86 на десктопах и ноутбуках.
Но от x86 они не избавились - хотя бы в виде эмулятора он остался. И сомневаюсь, что избавятся в ближайшей перспективе. Хотя бы потому, что эмуляция x86 работает действительно хорошо и сценарий "допилю работу ПО на эмуляторе" выглядит лучше чем "перепишу ПО под ARM".
napa3um
Не очень понял сути ваших возражений. Я говорю о том, что роль монополий на рынке для внедрения того или иного варианта технологии оказывается важнее технических несовместимостей между этими вариантами технологий, а вы говорите, что несовместимости в технологиях преодолеваются, хоть и неидеально, и преодолеваются в том числе за счёт монопольного контроля экосистемы. Вроде как подтверждаете мои слова, но почему-то в форме возражения :).
SabMakc
Возражение в том, что тот же Apple не избавился от наследия x86 при всех своих финансовых возможностях.
Да, они сделали очень значительный шаг в этом направлении. Но в ближайшей перспективе x86 будет играть значительную роль в их экосистеме. А учитывая очень качественную эмуляцию x86 - я не уверен, что и в средне-срочной перспективе удастся полностью избавиться от наследия x86.
Хотя для избавления достаточно просто выключить Rosetta 2 при очередном обновлении... На что Apple вполне способен - они регулярно ломают обратную совместимость.
napa3um
«Я не думаю, что Эпл в ближайшее время сломают совместимость» - «Эпл вполне способны сломать совместимость и регулярно это делают». Я, пожалуй, пойду, вы и сами прекрасно можете с собой подискутировать, потом расскажете мне, что я имел ввиду, и почему это было неправильным :).
Armmaster Автор
Именно про экономическую причину (высокая стоимость портирования ПО) вся статья.
Пример Эппла просто показывает, что люди, которые изначально спроектировали свою бизнес-модель таким образом, чтобы максимально держать в своих руках всю экосистему и заранее позаботиться о возможности смены процессорной платформы - имеют такие вот преимущества. Но это не относится к рынку десктопов/серверов/ноутбуков, где совершенно другая ситуация и нет единого "держателя" экосистемы
Ага, ну вот и эксперты подъехали. Читаем по приведённой в статье ссылке стенограмму заседания:
Вы утверждаете, что абсолютно все вышеперечисленные участники заседания были подкуплены, серьёзно?
И снова возвращаемся к вопросу, что проблема портирования ПО - это как раз экономическая проблема, про что статья и написана
napa3um
Я делаю акцент на монополиях - основной проблеме капитализма, и да, все перечисленные вами люди были «подкуплены» в той или иной форме в том смысле, что даже «честный» и выгодный контракт с политическим конкурентом здесь и сейчас - это «продажа» суверенитета государства и поддержка существующей монополии. Работа по навязыванию технологического отставания СССР была шире, чем просто «вкусные» контракты или взятки, в ходе «холодной войны» пресловутому западу получилось заклеймить в союзе целую отрасль научных знаний (на самом деле не только кибернетику), создав в том числе отток специалистов и сворачивание множества программ. Это очень глубокая тема, но, боюсь, она выходит за рамки тематики ресурса, я лишь хотел отметить некоторую, так сказать, неполноту статьи (некоторую «лубочность» объяснений «лубочных» же историй :)).
F0iL
Трижды же, не? m68k -> powerpc -> x86_64 -> arm (до этого был ещё 6502, но это совсем уж древние времена)
napa3um
Да, пардон, посчитал переход m68k -> PowerPC уж слишком древним, не очень в курсе, насколько там софт отнаследовался (или там просто получился "полный перезапуск"), про 6502 -> m68k ещё меньше в курсе. Но подсчёт этих переходов лишь усиливает мою аргументацию :).
F0iL
Как пишут в интернете, при переходе с 68k на PowerPC, эмуляцию для совместимости со старым софтом они обеспечили: 1, 2, 3