Comments 40
Вот кстати насчёт индульгенции для GPU, который не на x86... Как раз когда я только начинал работать (в геймдеве) помню были обещания, что Intel скоро выпустит Larrabee, революционный GPU на x86. Доклады на SIGGRAPH и всё такое. Правда так и не вышло в итоге...
"Я решил написать книгу еще до того, как это стало мейнстримом."
Поддерживаю флэшмоб.)
Успехов и частых свиданий с музой Вам!
Я в этом не сильно большой специалист, но мне кажется, что выпуск Apple M1 показал, что x86 все-таки придется выбрасывать. И главная проблема тут именно legacy и то самое x86 compatibility, за которое держались больше 40 лет.
Можно получать соизмеримую с ARM производительность, но потреблять ты при этом будешь в несколько раз больше, а это тупик, что в мобильном, что в серверном сегменте.
Быстро не соскочить...уж больно много софта переписывать. Яблоку попроще в этом плане. Они весь свой стек контролируют...
Зачем переписывать?
Чаще всего просто перекомпилировать и если это изначально какой-нить linux, то сие есть достаточно тривиальное дело.
А если это .NET/Java/Python/node.js etc так вообще ничего делать не надо.
Таким образом, просто силами девопсов/эксплуатационщиков обойтись нельзя, это не повышение минорной версии питона, которая требует правки пары функций в коде.
Значит, нужна разработка. Значит, тестирование. Значит, сопровождение. Причем писать надо так, чтобы новая версия была кросс-платформенной, т.к. старые системы тоже в эксплуатации.
И это я уж не говорю о том, что разработка — это не только написание кода, это еще и отладка, и профилирование, и всякое-разное, для чего есть инструменты на существующих платформах, но не факт, что есть на новых.
А с интерпретируемыми языками геморрой сильно уменьшается, но не исчезает полностью: почти любой код на них зависит от внешних библиотек, а там рано или поздно встретится враппер, который передает данные в бинарник. А с ним те же проблемы, что и выше. И точно такие же проблемы встречаются в самих интерпретаторах, которые тоже бинарники под вполне определенную архитектуру.
Ну вы, как бэ, пытаетесь все это объяснять человеку, у которого был опыт дизайна и сопровождения огромной плюсовой кодовой базой, без проблем компилирующейся под три разные архитектуры и четыре операционные системы.
Если мы говорим не про какое-то присохшее легаси (которое почему-то в наши дни под x64 не собирается), то понятно, что затраты при портировании будут, но это очень далеко от истории "надо садиться и все переписывать с нуля".
Был бы бизнес интерес. А он однозначно будет, если, при прочих равных, дата центр начнет жрать в два раза меньше мощности.
С учетом того, что уже много лет разработка под мобильные платформы стала сильно больше, чем работка под классический десктоп, а мир GNU на кросс платформу был ориентирован всегда, полагаю, что картина в целом не столь уж и печальна.
И это мы, заметьте, говорим о чистом native коде, а не о Java или там node.js, за которыми огромные доли рынка.
Тяжелое для портирования легаси, безусловно, существует, но полагаю, что доля его не существенная (именно по занимаемому объему серверного рынка).
Даже если бы M1 представлял из себя нечто уникальное и действительно выдающееся, если бы он был доступен всем, если бы он был действительно всеядным и нужным, то и тогда миграция заняла бы лет 10-20.
Корпоративный сектор весьма консервативен и "вау-сюси-пуси" эффектом не страдает. Если что-то работает, то менять это, без должной причины нет. Профит от мнимой энергоэффективности - ничтожен, по сравнению с заменой громадного парка систем, трат на утилизацию старых и прочих вложений в переходный период.
У ARM есть своя, вполне оправданная ниша в серверном сегменте, но маркетинговое недоразумение от огрызка на это никак не влияет и влиять не может.
M1 это вектор, который показывает в какую сторону дело идет.
И ваша оценка "10-20 лет" это обслюнявленный и поднятый кверху палец. И разглагольствования о том, что для дата центров энергоэффективность это мнимая проблема, сильно оторваны от реалий.
Дядь, до сих пор в ходу софтварные системы, написанные в 70х. Попытки перейти на что-то более современное, провалились. Поэтому слава IBM, которая до сих пор тащит в мейнфреймах обратную совместимость с чуть ли не первыми своими железками.
Так что 20 лет это еще очень оптимитистично.
Понятно, что есть легаси, но я думаю, что его не так уж и много в сравнении с дата центрами гигантов типа Амазон или Google.
А у этих ребят, я уверен, code base не настолько плох, чтобы его было бесконечно долго и дорого портировать под ARM.
И скорее всего, Google будет заменять не CPU, а то, на что у них приходится больше вычислений — для нейросетей они сделали свой TPU, управляющий модуль может быть хоть x64, хоть ARM — не принципиально.
Корпоративный сектор весьма консервативен и «вау-сюси-пуси» эффектом не страдает. Если что-то работает, то менять это, без должной причины нет. Профит от мнимой энергоэффективности — ничтожен, по сравнению с заменой громадного парка систем, трат на утилизацию старых и прочих вложений в переходный период.
Вы явно оцениваете только кусочек корпоративного спектра, всякие сервера, которые стоят в ДЦ для очень больших компаний. Но это не весь рынок.
Во-первых, никто не говорит про замену парка систем, а говорится про миграцию. Старые сервера выводятся из эксплуатации, новые вводятся. И не обязательно они на х86. Если софт не в бинарниках, а та же джава, проблем в миграции становится сильно меньше, лишь бы виртуальная машина работала с нормальной производительностью.
Во-вторых, помимо банков из первой десятки есть много средних компаний, которым 20% экономии на костах за сервера — весомая причина перейти на альтернативу. Заодно у них и нет настолько больного легаси, чтобы миграция превратилась в нерешаемую проблему.
В-третьих, корпоративный сектор — это еще и облачные решения SAAS. И вот у их поставщиков очень ощутимая часть OPEX — это эксплуатация серверов. Одно дело, когда у вас вся IT-инфраструктура занимает 10% расходов компании и экономия 20% из этих 10% — хрен с ней, никого особо не заботит, другое дело, когда у вас в компании IT-инфраструктура — это 80% расходов.
В-четвертых, внешние факторы: зеленая повестка и опасность санкций. Будет тренд «снижаем выбросы за счет экономии электроэнергии», пойдут менять сервера, не взирая на экономическую целесообразность, как сейчас с кэнселингом русских. И если уж начали говорить об этом — что будут закладывать компании в инфраструктурный план, если они допускают возможность санкций? Ну понятно, что в европе и америке этот вопрос не критичен, там скорее зеленая тема играет, но вот в азии и ближнем востоке все наоборот — на зеленых всем плевать, а вот в поведение интела в отношении россии они наверняка видят риск: завтра поссорятся с сша и европой они, и ковровые бомбардировки начнутся уже в отношении них. И тут какой-нибудь китайский арм-процессор общего назначения выглядит привлекательнее интела, даже несмотря на сырость/стоимость/сложность/етс.
Да, сейчас M1 это игрушка для пользователей, которую нельзя взять и перенести на всю инфраструктуру. Но даже эта игрушка уже показывает, что да, возможно. Да, через десять лет, но х86 придется выбросить (ну оставить в десяти процентах легаси-систем, ок,
как сейчас мейнфреймы живут). И интел, следуя текущему курсу и трясясь над своим ISA, просрет и оставшийся большой рынок, как просрал мобильный.
Или еще забавнее: у меня мак корпоративный стандарт. А новые маки на х86 того... Кончились. И пошли костыли чтоб то что есть заработало. Вот и переход так будет с велосипедами и костылями.
Если что крупная западная корпорация.
На ARM же делают законченные устройства, и каждое с другим не совместимо (по bootloader и linux kernel). Вот когда материнские платы под ARM будут производить с пяток фирм, да так, чтобы в любую втыкай CPU, RAM, Video — и оно заведётся, и чтобы ОС ставилась одна на любую такую систему, а не требовала допиливания под SoC, вот тогда для x86 и придёт конец.
Но этот процесс двигается в том числе и популяризацией ARM, которую тащат и серверные и пользовательские девайсы
Я в этом не сильно большой специалист, но мне кажется, что выпуск Apple M1 показал, что x86 все-таки придется выбрасывать
ИМХО система команд играет пренебрежимо малую роль в успехе m1
полагаю, что играет, x86 сильно много транзисторов уходит на поддержку легаси плюс чрезвычайно сложный декодер команд
сильно много транзисторов
и каков процент от общего числа транзисторов?
хз, но для меня это единственное рациональное объяснение того, что новички из Apple догнали метров по производительности да еще и получили в разы меньшее энергопотребление
Они сделали широкий процессор (8 конвейров против 4), потому что не были связаны cisc-декодером. В свою очередь, это позволило работать на существенно меньшей частоте (и напряжении), вписывающейся в рамки мобильных техпроцессов, что кратно снизило потребляемую мощность при тех же или лучших ops.
cisc-декодер, конечно, сложнее, чем risc, но по сравнению с общим транзисторным бюджетом его доля мизерна. Однако именно его ограниченность заставляет достигать параллелизма не относительно простым уширением процессора а использованием специальных simd-инструкций, что требует еще и переписывания софта.
Титанических размеров кэши тоже вносят свой вклад.
https://news.ycombinator.com/item?id=35941183 вот обсуждают
(пардоньте за некрокоммент, только добрался до этого цикла. но статья ещё раньше)
Мне Интел сейчас напомнил Тойоту в Формуле 1. Если вкратце - ребята, имея самый большой бюджет среди всех команд и заводскую поддержку в течение 8 лет, так и не добились ни одной победы в гонке. Причина? Ребята были слишком консервативны и делали все "по-японски". Такое ощущение, что не хотели побеждать, а именно следовать своему пути. В то время как топы боролись с реальными проблемами (как и АМД). Ушли из-за финансового кризиса в 2009. Некоторые помнят слезы тогдашего босса с говорящей фамилией Ямашина (поливановцы, не убивайте).
P.S. Не уверен, что у меня часто получится выдавать подобные многостраничные фолианты. Для баечек попроще и покороче, которые, надеюсь, тоже войдут в книгу, у меня есть телеграм-канал “Китайский русский”.
Как раз оптимальное количество текста для статьи. Первые две все же были коротковаты, а вот столько как раз сколько нужно.
Спасибо, очень интересно читать
Давно интересно: а в итоге вообще были какие-то реальные сценарии, где Itanium выигрывал и сработала эта идея "выкинем легаси x86 и заживем"? Или там все пошло не так?
Валерий, а какова судьба Soft Machines и их VISC после покупки Интелом?
Их просто купили, чтобы поглотить в зародыше, или всё таки из этого что-то получилось?
Про аквизишены будет отдельный текст. В качестве спойлера скажу только, что они в принципе как то прижились. Но их использование далеко от из начальных целей аквизишена.
Посты действительно интересные, спасибо. Но я не представляю, как из них можно сделать книгу. Разве что редактор заставит вас вместо каждой гиперссылки сделать сноску или врезку -- иногда на пару строк, а иногда на полстраницы.
Бабаян уволился из Интел?
IA64 (Itanium, etc.) был обречён на смерть именно из-за EPIC при непредсказуемой задержке доступа к памяти. Учитывая предшествующий опыт с Rambus, которая, в одном из вариантов, предполагала сократить эти задержки — связь, думаю, очень вероятна. Вот подробности истории с Rambus от инсайдера были бы интересны.
Сверхдлинный конвейер на сотни микрокоманд — свойство всех последних моделей и Intel, и AMD, и Apple, но частоты при этом не обязательно растут. Наверно, кто-то сможет прокомментировать, почему так получилось сейчас и не получилось 20 лет назад.
В остальном спасибо за интереснейшие рассказы...
Забавно всё-же, что в больших финансах/государствах etc. политическая подковёрная возня отдельных фигурантов влияет на исход для индустрии/картринку мира в целом гораздо сильнее, чем потенциальные прибыли, технологические достижения и прочие "интересные только задротам сущности". Спесивые людишки ради сиюминутного "посидеть на троне" готовы потопить годы работы тысяч талантливых людей, никогда не сомневаясь ни секунды.
Made at Intel. Architecture and religion — 3