Сегодня я заканчиваю первую главу (пока еще не написанной :)) книжки Made at Intel. Начало и продолжение – здесь и здесь.
Главная вера
И все же важнейшей религией компании является сама x86 Instruction Set Architecture. Intel изначально свято придерживался принципа backward compatibility - программы написанные для предыдущих поколений процессора работают на следующих без изменений (ну разве что требуют эмулятора операционки). Без этого нельзя построить никакой экосистемы, ибо ее формирование процесс занимающий многие годы. И именно благодаря последовательности Intel x86 ISA стала для компьютерного мира чем то вроде христианства. Аналогию можно продолжить сравнив разделение христианства на католическую и православную ветви – Intel и AMD (или наоборот). Но мы этого делать не будем. :) Однако принцип backward compatibility требует, чтобы любое изменение ISA оставалось в ней “навсегда”. И, наверно, нам следовало относиться к архитектуре более бережно. Когда я был маленьким, а деревья большими один умный человек (Ronak Singhal :)) говорил мне, что тут, дескать не о чем печалиться. С каждым shrink (переходом на более совершенный процесс изготовления чипов) площадь необходимая для поддержки legacy инструкций “сжимается” в два раза. Но вот когда Intel серьезно “застрял” на 10нм техпроцессе, мои опасения вернулись с удвоенной силой.
Отчасти, впрочем, наши промахи можно обьяснить тем, что x86 – “закрытый клуб” в отличие от ARM и тем более RISC-V. Ну, например, собирается ARM “выкатить” новую версию ISA. Он будет согласовывать ее со всем основными вендорами – Apple, Samsung, Qualcomm и тд. Поэтому у него куда меньше шансов совершить какую-нибудь глупость. Intel, конечно, тоже советуется с основными партнерами –Microsoft, Google, Amazon. Но основные решения все же принимаются внутри. Мне это почему-то представлялось так. На унылом Севере, вдали от людского жилья стоит темная башня. Лишь на последнем этаже ее горит свет. И там наверху собрались адепты тайного ордена... :) В случае с Интел “орден” имеет вполне конкретное название – ISA CPT. Именно там принимаются самые важные архитектурные решения. На этот митинг вхожи лишь ведущие технические лидеры компании компании – Fellows, Senior Principal Engineers. Мне трудно всерьез назвать себя одним из адептов (так, скорее, младшим послушником :)). Но я всегда был юношей любопытным и время от времени мне удавалось туда пролезть – (восьмым) со-докладчиком в какой нибудь презентации или просто “вольным" слушателем. Чаще все же приходилось довольствоваться информацией из вторых-третьих рук. И сегодня я немного расскажу вам о разного рода “ересях” которые зарождались и погибали внутри Интел..
Гибель Титаника
Хотя Itanium нарекли Титаником сразу же после анонса архитектуры 4 октября 1999го, он не был поначалу и вполовину так плох, как его реноме. Архитектура VLIW/EPIC смотрелась необычно по сравнению с CISC и манила новыми возможностями. Мою фантазию будоражили предикатное исполнение, вращающиеся регистры и explicit software pipelining. К тому же IA-64 была in-order архитектурой – можно было точно предсказать сколько будет обрабатываться один элемент достаточно длинного цикла при условии прогретых кэшей. Для кого как, а для меня эта “иллюзия контроля” почему-то всегда была важна. Тогда я еще плохо представлял себе важность software ecosystem для успеха платформы. Да, понимал, что работа предстоит огромная, но шансы представлялись вполне себе неплохими.
Но все же Itanium, как и Титаник, видимо, был проклят с самого начала. Дело в том, что против него играли как религия (not invented here!) так и политка. А в средневековом государстве – это необоримая сила. “Крестным отцом” Itanium был Mike Fister тогдашний глава серверного подразделения Intel. И в начале 2000х между ним и Полом Отеллини развернулась борьба за то, кто станет следующим CEO Intel после Kрейга Баррета. Борьбу эту Captain Itanic проиграл и ушел в CEO в Cadence (который, безусловно уважаемая компания, но все же не Intel). Также ко дну пошло его детище. А спасать было некому - Отеллини Itanium не жаловал. Уж не знаю вследствие “разборок” начала 2000х или по каким то другим причинам... К тому же обнаружилась масса других проблем.
Индустрия как то сразу не поверила в Itanium. Портирование софта шло без особого энтузиазма. А Intel не решился на большую ставку – Itanium enabling strategy всегда оставляла у меня ощущение какой то недосказанности...
Возможно расчет был на x86 compatibility block, но именно он стал больным местом Itanium – энергии потреблял больше чем весь остальной процессор и грелся как сволочь. Бинарный транслятор также не выглядел панацеей: пробразование из CISCа во VLIW является одним из самых сложных (хотя на Эльбрусе как то работает)...
Насколько увлекательным являлось написание микрокернелов для Itanium на ассемблере – настолько кошмарным было портирование приложений. Компилятор является основным камнем преткновения для архитектуры VLIW/EPIC. Одно из немногих исключений, которое я знаю – опять же Эльбрус. Но для того чтобы довести его компилятор до ума потребовалось порядка 20 лет. Интел столько ждать не захотел...
Ну и последнее – Itanium всегда выпускался с отставанием на шаг по техпроцессу от x86. И в этом трудно не усмотреть наличие “доброй” политической воли.
IA-64 влачила жалкое существование до начала 20х. И лишь в феврале прошлого года Linus Torvalds сказал “It's dead, Jim." Но можно было спокойно сделать это и на 10 лет раньше. И все же у меня осталось от Itanium ощущение “неспетой песни”. Да, я не люблю VLIW (я тоже религиозен :)) и мне кажется, что рано или поздно мы бы все равно “уперлись” в его ограничения. Но все же стоило пытаться по-честному пройти этот путь ...
X-Files
Архитектура а StrongArm (а впоследствии XScale) еще одно наследие, полученное Intel от DEC. Было тогда в компании подразделение Intel Communication Group. Ваяло контроллеры для IO и сетевых устройств. И там неприхотливый и экономичный ARM пришелся весьма ко двору. Но именно в этот момент наступила эпоха handheld девайсов (наладонники, как их тогда называли) – предтеча современных смартфонов. Intel попробовал – и оно как-то сразу полетело. BlackBerry, Dell, Compaq, Toshiba, Palm, Amazon Kindle – вот далеко не полный список компаний, начавших производство продуктов на базе XScale. Воодушевившись, в 2004м Intel выпустил SIMD расширение ISA под названием Wireless MMX. И в отделе IPP (в котором я пребывал с 2002го по 2005й) закипела работа по оптимизации библиотек.
И вдруг... как гром среди ясного неба в 2006м грянула новость – Intel продает XScale бизнес Marvellу за жалких 600 миллионов долларов. Бросьте в меня камень – но я по чисто бизнесовым причинам, считаю это одной из самых больших ошибок компании. Недостатки этого решения более чем очевидны.
Мы в очередной раз “прокинули” своих кастомеров (впрочем, не первый и не последний)
Вместе с XScale ушла команда, наработавшая уникальную экспертизу в области мобильных устройств. И потом ее ой как не хватило...
XScale был “входным билетиком” в мобильную экосистему. А кому как не Intel понимать ее значение. И беспечно выбросив его – мы сами захлопнули дверь перед собственным носом.
Именно в тот момент, недооценив потенциал рынка смартфонов и планшетов Intel обрек на неудачу свои дальнейшие (дорогостоящие) попытки стать там существенным игроком. (Способности Intel предсказывать индустриальные тренды я еще коснусь в одной из следующих глав :)).
Объяснение у меня только одно, чисто религиозного характера. XScale был ARMом. Not made at Intel. Уже зрел в недрах компании Atom low-power процессор с “православным” набором команд. И Intel принял решение избавиться от “чужеродного” продукта.(Мне до сих пор представляется правильной стратегией на тот момент - тащить одновременно две линейки). Я сейчас выскажу очень спорную мысль – ни одна другая компания так бы не поступила. Но Intel, безусловно уникален в своей вере.
Поначалу Atom достиг определенного успеха в сегменте нетбуков и неттопов. Тут надо понимать, что Intel все еще играл на своем поле – батарейки у этих устройств мощнее чем у телефона, а стандартной операционкой является windows co всем набором классического x86 софта. А вот дальнейшее “наступление” в область смартфонов и планшетов успеха не имело. Экосистема уже полностью сложилась вокруг ARM и даже трюк Houdini – бинарный транслятор ARM->x86 не спас положения.
Но главная беда даже не в этом. Дело в том что мобильные процессоры – это с необходимостью System on Chip (SoC). По сути не так важно, какое ядро тащит операционную систему ARM или Atom – Android неплохо оптимизирован под оба. Важно то, что большинство стандартных функций – поддержка wireless, медиа кодеки, шифрование/дешифрование выполняются на отдельных IP-блоках. Мне довелось попасть на “разбор полетов” (вроде бы он тоже был на ISA CPT) по поводу этих функций. И там все говорили одно и то же – здесь конкуренты сделали на доллар дешевле, здесь на пол-ватта эффективнее и тп. Что совершенно неудивительно – пока мы решали вопрос религиозной чистоты, потом восстанавливали легкомысленно потерянную экспертизу, потом заново простраивали экосистему наши конкуренты занимались оптимизацией. Так что, как и в случае с Xeon Phi к неудачам Intel в мобильном сегменте ISA как таковая не имеет особого отношения. Просто мы упустили время, которое потом не смогли наверстать...
Индульгениця
Мне не сосчитать различных ISA которые нашли свой конец в Intel, не выдержав противостояния с X86. Впрочем есть одно исключение – встроенной интеловой графике всегда позволялось иметь instructions set, отличный от ортодоксального. Как будто она получила некую “папскую грамоту” которая хранила ее в самые темные времена костров инквизиции. Что можно обьяснить бизнесовыми причинами, но все равно немного удивительно. Но тем не менее интеловая графика продолжает жить с начала 2000х как независимая программируемая структура. Так, глядишь, и саму x86 переживет. :)
Ну и конечно мой рассказ об истории архитектуры был бы неполным, если не упомянуть о драматических столкновениях различных религиозных течений. Вообще история развивалась циклически – вначале “еретические” архитектуры плодились (хотя бы в виде экспериментальных проектов) и потом “консерваторы” собирались с силами и брали “кровавый реванш”. Я расскажу об одном случае 2013го года, когда “ортодоксы” Per Hammarlund и Bryant “Большой Полосатый Мух” Bigbee в один день “похоронили” проекты “вольнодумцев” VIP Бориса Бабаяна и Moonrun Дейва Дитцела (ex-Transmeta). Я тогда сумел просочиться на ISA CPT в день postmortemа. Арташесович отстрелялся минут за 10. Во-первых, он был расстроен. Во-вторых, длинные речи на английском ему не очень даются. Зато Дитцел выдал настоящее шоу. Там было все – картинки, жесты, эмоции и очень много стоящих мыслей. Наконец, спустя полтора часа Дейв открыл свой последний слайд “New Architectural Ideas at Intel”. Cлайд был пустой. В гробовой тишине заседание закончилось. Занятно, однако, что из 4х упомянутых мной Intel Fellow дольше всех продержался в конторе именно Бабаян (aж до декабря 21го). Дитцел отвалил практически сразу после описанных событий и создал свою фирму Esperanto Technologies. Hammarlund ушел в Apple в начале 2015го. Bigbee продержался немногим дольше...
Но мне особенно врезалось в память, как примерно спустя год после Варфоломеевой ночи на ISA CPT кто-то вдруг задал риторический вопрос.
-А помните тех, которых мы сожгли на костре в прошлый раз? Возможно они были не так уж и неправы...
P.S. Не уверен, что у меня часто получится выдавать подобные многостраничные фолианты. Для баечек попроще и покороче, которые, надеюсь, тоже войдут в книгу, у меня есть телеграм-канал “Китайский русский”.
Комментарии (24)
Sergey_Kovalenko
06.05.2022 19:05+4"Я решил написать книгу еще до того, как это стало мейнстримом."
Поддерживаю флэшмоб.)
Успехов и частых свиданий с музой Вам!
cdriper
07.05.2022 08:28Я в этом не сильно большой специалист, но мне кажется, что выпуск Apple M1 показал, что x86 все-таки придется выбрасывать. И главная проблема тут именно legacy и то самое x86 compatibility, за которое держались больше 40 лет.
Можно получать соизмеримую с ARM производительность, но потреблять ты при этом будешь в несколько раз больше, а это тупик, что в мобильном, что в серверном сегменте.
vvvphoenix Автор
07.05.2022 10:26+3Быстро не соскочить...уж больно много софта переписывать. Яблоку попроще в этом плане. Они весь свой стек контролируют...
cdriper
07.05.2022 12:39-4Зачем переписывать?
Чаще всего просто перекомпилировать и если это изначально какой-нить linux, то сие есть достаточно тривиальное дело.
А если это .NET/Java/Python/node.js etc так вообще ничего делать не надо.
vvzvlad
07.05.2022 13:33+8Нет, оно так не работает. В куче систем разработка и эксплуатация разделены и существуют на разных полюсах. И даже если есть возможность собрать из исходников, то в любой более-менее сложной системе нельзя обойтись make TARGET=arm64, после чего все заработает: даже при миграции 86=>64 возникает огромное количество геморроя, если софт изначально прибивался костылями к определенной архитектуре (ради скорости, например), чего уж говорить о миграции на кардинально другой набор команд.
Таким образом, просто силами девопсов/эксплуатационщиков обойтись нельзя, это не повышение минорной версии питона, которая требует правки пары функций в коде.
Значит, нужна разработка. Значит, тестирование. Значит, сопровождение. Причем писать надо так, чтобы новая версия была кросс-платформенной, т.к. старые системы тоже в эксплуатации.
И это я уж не говорю о том, что разработка — это не только написание кода, это еще и отладка, и профилирование, и всякое-разное, для чего есть инструменты на существующих платформах, но не факт, что есть на новых.
А с интерпретируемыми языками геморрой сильно уменьшается, но не исчезает полностью: почти любой код на них зависит от внешних библиотек, а там рано или поздно встретится враппер, который передает данные в бинарник. А с ним те же проблемы, что и выше. И точно такие же проблемы встречаются в самих интерпретаторах, которые тоже бинарники под вполне определенную архитектуру.cdriper
07.05.2022 18:05Ну вы, как бэ, пытаетесь все это объяснять человеку, у которого был опыт дизайна и сопровождения огромной плюсовой кодовой базой, без проблем компилирующейся под три разные архитектуры и четыре операционные системы.
Если мы говорим не про какое-то присохшее легаси (которое почему-то в наши дни под x64 не собирается), то понятно, что затраты при портировании будут, но это очень далеко от истории "надо садиться и все переписывать с нуля".
Был бы бизнес интерес. А он однозначно будет, если, при прочих равных, дата центр начнет жрать в два раза меньше мощности.
vvzvlad
07.05.2022 18:16+4А у меня опыт сопровождения стремного корпоративного софта с кучей легаси. И так как в это легаси влезать лишний раз не хочется, все правки там делаются костылями. Сделали, чтобы хоть как-то собиралось под х64 пять лет назад, перешли на новое железо, и все, не трогают. Собрать это под арм — это еще тонна геморроя. Реалистично, конечно, не спорю. Но далеко не «просто перекомпилировать», это срабатывает только там, где софт сразу писался с прицелом на кроссплатформенность. И то потом всплывает «ой, а у нас ничего не завелось, потому что в http-либе подключена бинарная библиотека шифрования, в которой у нужного нам алгоритма кусок написан на ассемблере и быстро его 1-в-1 не переписать, потому что у нашего процессора тупо нужные инструкции отсутствуют, оцениваем оптимистично в 10-20 ч∙д»
cdriper
07.05.2022 18:30С учетом того, что уже много лет разработка под мобильные платформы стала сильно больше, чем работка под классический десктоп, а мир GNU на кросс платформу был ориентирован всегда, полагаю, что картина в целом не столь уж и печальна.
И это мы, заметьте, говорим о чистом native коде, а не о Java или там node.js, за которыми огромные доли рынка.
Тяжелое для портирования легаси, безусловно, существует, но полагаю, что доля его не существенная (именно по занимаемому объему серверного рынка).
Schokn-Itrch
07.05.2022 11:28+1Даже если бы M1 представлял из себя нечто уникальное и действительно выдающееся, если бы он был доступен всем, если бы он был действительно всеядным и нужным, то и тогда миграция заняла бы лет 10-20.
Корпоративный сектор весьма консервативен и "вау-сюси-пуси" эффектом не страдает. Если что-то работает, то менять это, без должной причины нет. Профит от мнимой энергоэффективности - ничтожен, по сравнению с заменой громадного парка систем, трат на утилизацию старых и прочих вложений в переходный период.
У ARM есть своя, вполне оправданная ниша в серверном сегменте, но маркетинговое недоразумение от огрызка на это никак не влияет и влиять не может.
cdriper
07.05.2022 12:43+3M1 это вектор, который показывает в какую сторону дело идет.
И ваша оценка "10-20 лет" это обслюнявленный и поднятый кверху палец. И разглагольствования о том, что для дата центров энергоэффективность это мнимая проблема, сильно оторваны от реалий.
permeakra
07.05.2022 17:41+3Дядь, до сих пор в ходу софтварные системы, написанные в 70х. Попытки перейти на что-то более современное, провалились. Поэтому слава IBM, которая до сих пор тащит в мейнфреймах обратную совместимость с чуть ли не первыми своими железками.
Так что 20 лет это еще очень оптимитистично.
cdriper
07.05.2022 18:09Понятно, что есть легаси, но я думаю, что его не так уж и много в сравнении с дата центрами гигантов типа Амазон или Google.
А у этих ребят, я уверен, code base не настолько плох, чтобы его было бесконечно долго и дорого портировать под ARM.
qw1
09.05.2022 00:00Если говорить про Amazon и Google, они могут спроектировать свой собственный процессор, и на него пересесть на основном массиве серверов, но остальным что делать? В массы эти решения не пойдут, потому что для FAANG это не профильный бизнес — продавать железо.
И скорее всего, Google будет заменять не CPU, а то, на что у них приходится больше вычислений — для нейросетей они сделали свой TPU, управляющий модуль может быть хоть x64, хоть ARM — не принципиально.
vvzvlad
07.05.2022 13:18+5Корпоративный сектор весьма консервативен и «вау-сюси-пуси» эффектом не страдает. Если что-то работает, то менять это, без должной причины нет. Профит от мнимой энергоэффективности — ничтожен, по сравнению с заменой громадного парка систем, трат на утилизацию старых и прочих вложений в переходный период.
Вы явно оцениваете только кусочек корпоративного спектра, всякие сервера, которые стоят в ДЦ для очень больших компаний. Но это не весь рынок.
Во-первых, никто не говорит про замену парка систем, а говорится про миграцию. Старые сервера выводятся из эксплуатации, новые вводятся. И не обязательно они на х86. Если софт не в бинарниках, а та же джава, проблем в миграции становится сильно меньше, лишь бы виртуальная машина работала с нормальной производительностью.
Во-вторых, помимо банков из первой десятки есть много средних компаний, которым 20% экономии на костах за сервера — весомая причина перейти на альтернативу. Заодно у них и нет настолько больного легаси, чтобы миграция превратилась в нерешаемую проблему.
В-третьих, корпоративный сектор — это еще и облачные решения SAAS. И вот у их поставщиков очень ощутимая часть OPEX — это эксплуатация серверов. Одно дело, когда у вас вся IT-инфраструктура занимает 10% расходов компании и экономия 20% из этих 10% — хрен с ней, никого особо не заботит, другое дело, когда у вас в компании IT-инфраструктура — это 80% расходов.
В-четвертых, внешние факторы: зеленая повестка и опасность санкций. Будет тренд «снижаем выбросы за счет экономии электроэнергии», пойдут менять сервера, не взирая на экономическую целесообразность, как сейчас с кэнселингом русских. И если уж начали говорить об этом — что будут закладывать компании в инфраструктурный план, если они допускают возможность санкций? Ну понятно, что в европе и америке этот вопрос не критичен, там скорее зеленая тема играет, но вот в азии и ближнем востоке все наоборот — на зеленых всем плевать, а вот в поведение интела в отношении россии они наверняка видят риск: завтра поссорятся с сша и европой они, и ковровые бомбардировки начнутся уже в отношении них. И тут какой-нибудь китайский арм-процессор общего назначения выглядит привлекательнее интела, даже несмотря на сырость/стоимость/сложность/етс.
Да, сейчас M1 это игрушка для пользователей, которую нельзя взять и перенести на всю инфраструктуру. Но даже эта игрушка уже показывает, что да, возможно. Да, через десять лет, но х86 придется выбросить (ну оставить в десяти процентах легаси-систем, ок,
как сейчас мейнфреймы живут). И интел, следуя текущему курсу и трясясь над своим ISA, просрет и оставшийся большой рынок, как просрал мобильный.
max851
07.05.2022 14:08+3Или еще забавнее: у меня мак корпоративный стандарт. А новые маки на х86 того... Кончились. И пошли костыли чтоб то что есть заработало. Вот и переход так будет с велосипедами и костылями.
Если что крупная западная корпорация.
qw1
09.05.2022 00:06+2Огромная сила x86 в стандартизации. Шины, BIOS (EFI), периферия.
На ARM же делают законченные устройства, и каждое с другим не совместимо (по bootloader и linux kernel). Вот когда материнские платы под ARM будут производить с пяток фирм, да так, чтобы в любую втыкай CPU, RAM, Video — и оно заведётся, и чтобы ОС ставилась одна на любую такую систему, а не требовала допиливания под SoC, вот тогда для x86 и придёт конец.
schw0reismus
07.05.2022 16:46+4Мне Интел сейчас напомнил Тойоту в Формуле 1. Если вкратце - ребята, имея самый большой бюджет среди всех команд и заводскую поддержку в течение 8 лет, так и не добились ни одной победы в гонке. Причина? Ребята были слишком консервативны и делали все "по-японски". Такое ощущение, что не хотели побеждать, а именно следовать своему пути. В то время как топы боролись с реальными проблемами (как и АМД). Ушли из-за финансового кризиса в 2009. Некоторые помнят слезы тогдашего босса с говорящей фамилией Ямашина (поливановцы, не убивайте).
PsyHaSTe
08.05.2022 01:49+6P.S. Не уверен, что у меня часто получится выдавать подобные многостраничные фолианты. Для баечек попроще и покороче, которые, надеюсь, тоже войдут в книгу, у меня есть телеграм-канал “Китайский русский”.
Как раз оптимальное количество текста для статьи. Первые две все же были коротковаты, а вот столько как раз сколько нужно.
Спасибо, очень интересно читать
ganzmavag
08.05.2022 19:04+1Давно интересно: а в итоге вообще были какие-то реальные сценарии, где Itanium выигрывал и сработала эта идея "выкинем легаси x86 и заживем"? Или там все пошло не так?
qw1
09.05.2022 00:21+1Itanium делали как 64-битный x86, тогда ещё не было amd64.
То есть, на старте от был интересным, а когда вышел x64, там уже сравнивать напрямую нельзя — в статье упоминалось, что Itanium отставал по тех. процессу, да и развивать его уже перестали.
lifemaker
Вот кстати насчёт индульгенции для GPU, который не на x86... Как раз когда я только начинал работать (в геймдеве) помню были обещания, что Intel скоро выпустит Larrabee, революционный GPU на x86. Доклады на SIGGRAPH и всё такое. Правда так и не вышло в итоге...
vvvphoenix Автор
Про это я в предыдущей главе писал. Larabee переродился в knights ferry, потом кnights corner, потом knights landing... А потом всю линейку похоронили :)