На днях появилась новость о том, что из ядра Linux 6.7 полностью уберут код, который связан с архитектурой IA-64 и процессорами Intel Itanium. При этом Линус Торвальдс еще два года назад назвал процессоры Intel Itanium «потерянными» для ядра Linux. При этом в свое время Itanium казались вполне перспективными. Что могло пойти не так?
Из Linux полностью уберут архитектуру и поддержку процессоров
Речь действительно идет о том, что программный код, который обеспечивает работу процессоров Intanium с архитектурой IA-64, будет полностью удален. О том, что это рано или поздно произойдет, говорил в свое время и сам Торвальдс, но точная дата прощания с устаревшей технологией не называлась.
Причина удаления поддержки этих процессоров и архитектуры в том, что никто из комьюнити не собирался заниматься дальнейшей поддержкой технологии. Ну а поскольку самих систем на базе Itanium не так много, да и вряд ли их владельцы активно обновляют ПО, то смысла в дальнейшем «перетягивании» ненужного кода из релиза в релиз никто не видит.
В том, что код уберут, есть и плюс, поскольку ядро разом «похудеет» примерно на 65 тысяч строк кода. Правда, в текущей версии ядра, это 6.6, поддержка архитектуры сохраняется. Ну а поскольку 6.6 является LTS-релизом, т.е. с длительным сроком поддержки, то владельцы систем с процессорами Itanium могут быть спокойны вплоть до 2026 года, когда ядро прекратят поддерживать. Но вполне возможно, что поддержка именно этой версии ядра будет продолжена, так что удаление кода из ядра 6.7 не означает, что все системы на базе Itanium с Linux разом «превратятся в тыкву».
Интересно, что архитектуру, возможно, поддерживали бы и дольше, если бы не произошла необычная ситуация. Дело в том, что в 2021 году один из разработчиков случайно сделал так, что сборку ядра под Itanuim стало невозможно выполнить. Эта проблема оставалась незамеченной более месяца, пока на нее не обратил внимания сам разработчик.
Узнав об этом, Линус Торвальдс сделал закономерный вывод о том, что код IA-64 в Linux никто не поддерживает по причине его ненужности. Случилось все это в то время, когда Intel еще выполняла заказы на производство аппаратного обеспечения на базе Itanium. Но, как видим, никто не обратил внимания на проблему.
Что с Itanium не так?
Принято считать, что эпоха Itanium началась в 2001 году — с момента выхода первого процессора новой архитектуры. Тем не менее, о совместной работе Intel и HP над новой 64-разрядной архитектурой стало известно еще в 1994 году. Возможности впечатляли — 64-битные процессоры позволяли работать с большим диапазоном чисел, они более эффективны в параллельных и матричных вычислениях. В начале 90-х компания Intel вела разработку собственной 64-битной архитектуры P7, но довести дело до конца не сумела, поскольку возникло сразу несколько сложностей. Правда, работа не была проделана напрасно — некоторые наработки были внедрены в Itanium.
Сначала все было хорошо
В 1997 году была представлена лишь архитектура, после чего партнеры заявили о масштабных планах по созданию семейства чипов IA-64 (Intel Architecture). В 1999 году были готовы тестовые образцы процессора, тогда же компания Intel рассказала об этом проекте, плюс партнеры, Intel и HP, ввели термины IPF (Itanium Processor Family) и Itanium Architecture. В 2000 году появились тестовые образцы оборудования на основе новых процессоров, плюс компании активно демонстрировали возможности оборудования на разных мероприятиях. Тогда же Intel открыла около 30 центров разработки приложений, которые давали возможность разработчикам разрабатывать и оптимизировать ПО под системы на основе Itanium.
Intel тогда заявила, что архитектура Itanium — наиболее значительная разработка компании со времени создания 386-го процессора в 1985 году. Производительность процессора составила 6,4 млрд операций с плавающей запятой в секунду. Процессор мог выполнять до 20 операций одновременно, адресуя до 16 ТБ памяти при пропускной способности до 2,1 ГБ/с. А еще в чипе была реализована поддержка всех расширений Intel, включая технологии MMX, SIMD, симметричная мультипроцессорная обработка.
Наконец, Intel Itanium — микропроцессор на архитектуре IA-64 (EPIC), разработанный совместно компаниями Intel и Hewlett-Packard, был представлен 29 мая 2001 года. Казалось бы, все идет хорошо, потенциальные покупатели ожидали чип, отрасль была хорошо «прогрета».
Но что-то пошло не так
Презентация была воспринята с энтузиазмом, но затем последовали реальные тесты и фидбеки покупателей. Как оказалось, первое поколение Itanium потребляло очень много энергии, процессорам требовались мощные системы охлаждения. Кроме того, эти процессоры были дорогими, так что не каждая компания решилась на массовые закупки — ведь и оборудование на базе этих чипов тоже получалось дорогим.
Как и говорилось выше, Intel и HP хотели запустить и линейку процессоров для настольных компьютеров, но этого никогда так и не случилось. Плюс через пару лет после выхода Itanium компания AMD нанесла проекту сильный удар, представив первые 64-битные процессоры на архитектуре x86 (Opteron на архитектуре AMD K8 с набором инструкций AMD64). Intel пришлось бросить значительные ресурсы на создание собственной 64-битной версии x86, а вот Itanium на время стал вторым по значимости проекта. Но после того, как 64-битные процессоры на архитектуре x86 стали доступны, оказалось, что именно их активнее всего закупают производители серверного оборудования. А вот Itanium были не такими популярными.
Была и еще одна сложность — сложности с компилятором. Так, в программном коде было очень непросто выявлять независимые по данным команды для выполнения на VLIW-машине. Слишком много NOP-команд оказывалось в результате в связках (bundles) сверхдлинного слова. Эту проблему, насколько можно судить, изначально недооценили, а потом уже было поздно что-то менять.
Долгий период угасания
Если бы во время разработки архитектуры и процессоров Intanium кто-то из разработчиков одним глазком заглянул в будущее и увидел дату окончания поддержки архитектуры, то посчитал бы эти чипы крайне успешными. Ведь столько продержаться на плаву способна далеко не каждая технология.
Но на самом деле Itanium подбили еще на взлете, если так можно выразиться. Так, еще в 2010 году корпорация Microsoft заявила, что ОС Windows Server 2008 R2 станет последней серверной ОС с поддержкой Itanium. После этого и другие компании стали делать похожие заявления. Например, в 2011 году Oracle анонсировала прекращение поддержки ПО для Itanium.
Ну а чуть позже процессоры Xeon стали конкурировать с Itanium — в частности, их функциональность сравнялась. Intel в 2012 году смогла реализовать в 15-ядерном Xeon E7 v2 даже больше возможностей, чем в Itanium.
Все было бы совсем плохо, если бы не покупатели серверных систем. Их закупили многие компании, и понятно, что бизнес просто не мог себе позволить выбросить все это на свалку и покупать новое оборудование. По этой причине серверные системы работали еще много лет, а Intel оказывала поддержку.
Но в любом случае, технология понемногу умирала. Так, в 2019 году Intel выпустила уведомление об изменении продукта (product-change notification) под номером PCN116733-00. В документе говорилось о прекращении выпуска процессоров Itanium 9700 с кодовым названием Kittson, последних чипов семейства на рынке.
Другие интересные материалы
Комментарии (29)
jpegqs
06.11.2023 05:34+10Была и еще одна сложность — сложности с компилятором. Так, в программном
коде было очень непросто выявлять независимые по данным команды для
выполнения на VLIW-машине. Слишком много NOP-команд оказывалось в
результате в связках (bundles) сверхдлинного слова. Эту проблему,
насколько можно судить, изначально недооценили, а потом уже было поздно
что-то менять.Это сложности не с компилятором, если имеется в виду что компилятор плохо компилирует. Это проблема любых VLIW, что для оптимальной компиляции для них нужны данные профилировки на типовых данных/операциях. Иначе компилятор не знает в какую сторону оптимизировать. Расставлять подсказки для компилятора вручную - тяжело, мало кто этим занимается (вы могли заметить макросы likely/unlikely в некотором коде, но это не распространено повсеместно). Некоторые разработчики добавляют перекомпиляцию по профилю собранному на типовых данных, но это тоже редкость.
vk6677
06.11.2023 05:34+1В свой проект в качестве исследования решил поставить директивы likely/unlikely в условиях и операциях ветвления. Посмотрю что из этого выйдет.
jpegqs
06.11.2023 05:34Зависит от архитектуры, и "горячести" кода в который вы будете расставлять эти хинты для компилятора. Использование -fprofile-generate/-fprofile-use даст компилятору те же данные по всему коду (что был использован при профилировании). Скорее всего вы ничего не заметите. Для x86 это результаты в пределах погрешности, потому что погрешность высокая когда процессор может менять частоту.
JordanCpp
Дороговизна
Сложность
Тормозная эмуляция x86
Вендор лок
Jianke
Это ключевое.
JordanCpp
Да пресловутая совместимость. Сколько архитектур она убила.
Jianke
Это вопрос практического применения этой архитектуры (несовместимость очень сильно сужает эти рамки).
13werwolf13
apple неоднократно показывали что это всё фигня
да и линуксоиды (из тех у кого не установлен steam) тоже вполне безболезненно на aarch64 пересаживаются
и только в мире масдая всё сложно..
Jianke
Apple все проблемы добровольно-принудительно вешает на разработчиков.
У Linux вроде всё является open-source, и не разработчик, а сам сильно продивнутый пользователь сам занимается перекомпиляцией.
В случае Windows никто не запрещает разработчику забить на геморой.
haryaalcar
Прозрачная эмуляция со времён перехода с Motorola 68000 на PowerPC и заканчивая сегодняшней Rosetta, мультиархитектурные fat binary как бэ намекают, что всё немножко не так.
JordanCpp
10-20 лет назад всё зависели от windows и её совместимость с софтом. Сейчас ситуация серьёзно поменялась. Больше софта под Linux и. т. д
Jianke
Больше всего софта под
khajiit
Waydroid =)
DMGarikk
Эппл сервера практически никогда не выпускала, учитывая что в мире кобол до сих пор в ходу, очень безответственно рубить совместимость со словами "надо будет сами приползете"...не приползут, итантиум тому пример
13werwolf13
приползут, arm тому более свежий пример, как раньше power архитектура.
DMGarikk
так приползают к x86, а там где рубят совместимость со словами "вам не надо, у нас лучшие технологии" - все скатывается в нишевые решения
и повторсь, IA64 тому пример...все приползли в IA32 где всё устарело но совместимость...и амд тут удалось подыграть с о своей -64
13werwolf13
IA64 плохой пример, ибо было совсем уж давно
но мы имеем более современные примеры, в эпоху когда переход на другую архитектуру не требует нескольких лет подготовки, в эпоху когда новые архитектуры делают лучше а не хуже чем старые.. приползут, вернее уже приползли..
maxcat
Так-то винда первая из популярных декстопных систем, которая начала полноценную поддержку арм и "прозрачной" эмуляции там х86
Да и в целом Microsoft всегда была за совместимость: тот же dotnet делался чтобы не забивать себе голову какая там именно архитектура у ЦПУ; а ещё UWP вообще стёрла разницу между мобильной и дектопной ОС - пока апол даже не могла добиться совместимости даже между своим 6 и 10 айфонами с одинаковыми процессорами
13werwolf13
ахахахахахахахах
я просто напомню что в arm винде совершенно не было софта до емнип 2021 года, они даже свой собственный офисный пакет осилили собрать под arm вот недавно. да и по сей день в arm винде нечего ловить, тогда как под linux большинство софта есть под aarch64, ну и яблоки там чёт догнать пытаются (правда на костылях в виде ретрансляции x86 запросов в arm).
dotnet ужасен, да и практически мёртв за пределами одной, далеко не самой лучшей, платформы. UWP не стёрло разцины между десктопом и мобилой, UWP пытается превратить десктоп в мобилу (а ещё UWP совсем мертво за пределами масдая так что в серьёз не рассматривается даже если перестанет быть какашкой). если хотите пример вменяемого фреймворка созданного стереть границы между мобильным и десктопным миром посмотрите на kirigami.
DMGarikk
сейчас набегут адепты C# со словами что в линухе он давно и успешно работает
у вас явно устарели знания про дотнет
разве эту движуху не эппл начал и сам же не потянул, а MS попытались и тоже нет?
вообше насколько я вижу попытки превратить десктоп в мобилу прекратились... о сих пор помню странную тач менюшку настроек в фаерфоксе которую довольно быстро закопали ибо бред какойто
13werwolf13
бинго, эти два брата дегенерата вечно творят какую-то дичь, а юзвери потом пытаются убедить себя что им это нравится..
maxcat
У вас слишком предвзятое мнение. Минимально полноценный office уже в 2012 был социально доступен под arm на винде. Тогда же начали неофициально делать эмуляторы из х86 в arm для виндовс, и неофициальный компиляторы win32 под arm (официально был только winrt, он же ранее название UWP)
В 2018м пересмотрели подход к arm винде и официально выкатили бесшовный эмулятор x86 в arm, а так же начали выкатывать компиляторы для win32 под arm.
Со временем собрали под arm Винду разный софт, в том числе актуальную версию Office, Photoshop (я конечно не сторонник продуктов Adobe, но как там дела на линуксе?)0), Visual Studio. А то что не собрали работает через бесшовную эмуляцию, в том числе игры (это такая штука, ради который на aerm линуксе нужно кроме эмуляции х86 ещё и притворяться виндой)0))
Dotnet живёт вообще везде, в том числе куча линуксовых серверов крутят приложения на dotnet. А если для вас он ужасен, то что лучше? У dotnet из прямых конкурентов только более тормозная джава.
Kirigami это какой-то нонейм мертвый за пределами обычного мобильного андроида (то есть форка линукса) и декстопного линукса? Тот же UWP гораздо известнее и не был ограничен только мобилками и плоскими мониторами декстопа, а так же работает на игровых консолях и даже в Mixed Reality. А на декстоп UWP наконец-то принесла ограниченный жизненный цикл приложений - то есть приложение не будет плодить тонны мусора в автозагрузке и в фоновом режиме есть кучу ресурсов в пустую потому что его разработчики так захотели. В итоге на ноутбуках и планшетах был сильный выигрыш по автономной работе. Да и на стационарных компах не приходилось докупать ОЗУ вагонами. А к мобиле модно было подключить монитор и получить декстопный гуй в приложениях. А в Mixed Reality можно было размещать окна приложений по всей комнате + иметь полную иммерсивность управляя с помощью просто рук и глаз.
13werwolf13
разве, или вы это "блокнот" так нежно обозвали "минимально полноценный", это вообще взаимоисключающие слова..
это называется свернули не туда, сейчас apple на те же грабли наступил
ахаха, без коментариев))
а вы точно не в выдуманном мире живёте?
kirigami жизнеспособен на любой платформе с графикой, и винде, и линуксе и прочих (разве что кроме ios, но там в целом всё плохо с выбором фреймворков), просто пока не очень популярен (ну камон, ему безгоду неделя). и при этом он не пытается превратить десктоп в мобилу как UWP, и не пытается превратить мобилу в десктоп, он просто удобен и там и там.
UWP работает на консолях.. ну я рад за него, но это не делает его менее ужасным..
докупать ОЗУ тоннами.. так мы вроде не про браузеры речь ведём, а кроме браузеров сейчас на десктопе только телега любит по памяти утекать, ну и всякие dotnet и java поделия.
DMGarikk
Вы явно не в курсе насколько ява проникла в айти и насколько она влияет на все в нашей жизни, и дотнет - созданный по её образу и подобию пытается в эту сферу тоже
и учитывая что вы считаете что ява тормозит...это смешно конечно ;)
вы на сях наверное пишите?
reiser
А почему не туда? Можно подробности?
Как пользователю - отлично, старые приложения работают, как работали, а новые работают быстрее.
13werwolf13
растянули этап переезда до бесконечности..
reiser
Apple перешла на intel в 2005 (OS X 10.4) и откалась от поддержки power pc в 2009 (OS X 10.6), я думаю что и в этот раз длительность "бесконечности" будет недолгой
13werwolf13
сложно прогнозировать
с одной стороны раньше софта было меньше и он был "попроще", с другой стороны сейчас для портирования часто вообще не надо ничего делать кроме как просто собрать те же исходники под другую архитектуру (да, далеко не всегда всё так просто, но в случае aarch64 больше половины зависимостей были подготовлены к портированию задолго до того как в apple вообще узнали что такое ARM).
к тому же сейчас всё чаще слышишь от разрабов что "бизнес решил что выгоднее пойти более быстрым пусть и неправильным путём"..