Комментарии 60
Что пошло не так с Itanium?
Дороговизна
Сложность
Тормозная эмуляция x86
Вендор лок
Да пресловутая совместимость. Сколько архитектур она убила.
apple неоднократно показывали что это всё фигня
да и линуксоиды (из тех у кого не установлен steam) тоже вполне безболезненно на aarch64 пересаживаются
и только в мире масдая всё сложно..
10-20 лет назад всё зависели от windows и её совместимость с софтом. Сейчас ситуация серьёзно поменялась. Больше софта под Linux и. т. д
Эппл сервера практически никогда не выпускала, учитывая что в мире кобол до сих пор в ходу, очень безответственно рубить совместимость со словами "надо будет сами приползете"...не приползут, итантиум тому пример
не приползут, итантиум тому пример
приползут, arm тому более свежий пример, как раньше power архитектура.
так приползают к x86, а там где рубят совместимость со словами "вам не надо, у нас лучшие технологии" - все скатывается в нишевые решения
и повторсь, IA64 тому пример...все приползли в IA32 где всё устарело но совместимость...и амд тут удалось подыграть с о своей -64
IA64 плохой пример, ибо было совсем уж давно
но мы имеем более современные примеры, в эпоху когда переход на другую архитектуру не требует нескольких лет подготовки, в эпоху когда новые архитектуры делают лучше а не хуже чем старые.. приползут, вернее уже приползли..
в эпоху когда переход на другую архитектуру не требует нескольких лет подготовки
ага, каким способом это происходит то? это так просто потому что шарп, ява и питон во все щели
вопрос тут о суровом ентерпрайзном легаси написанном в 80-90е годы на сях ископаемых годов, никто не будет переписывать или перекомпилировать этот софт, эта задача годы займет и не факт что будет дешевле чем тащить древние архитектуры до упора
это так просто потому что шарп, ява и питон во все щели
совсем нет, просто сейчас всё меньше кода завязанного на какую-то конкретную ОС и/или платформу и всё больше открытых либ которые уже написаны умными людьми и используются тысячами других проектов, а главное прекрасно собираются и работают где угодно
только не весь сложный проприетарный софт пишется такими людьми
что толку от открытых отличных либ, если софтина управления ядерным реактором написана под конкретную архитектуру
эта софтина использует эти самые открытые либы, но да, если она написана так что портировать её будет больно то разноработчики - ССЗБ ибо рано или поздно портировать таки прийдётся, и чем раньше начать готовить для этого почву тем меньше болей пониже спины будет когда момент настанет.
то разноработчики - ССЗБ
парадоксально, но почти в каждом проекте где я был, было кактоето дикое кастомное решение, или кактойто чудный сборщик или либа с гитхаба непонятного происхождения или сотня bash файлов, или самопальный ci/cd, на обычных довольно свежих проектах
как вам ci/cd питонячего проекта через make файлы? что за наркомания....а бывает оказывается...
на самом деле даже открытый софт не панацея от отсутствия странных идей в голове разработчиков
но почемуто у корпоративных оно цветет в двойне сильнее... факт
ну у интел это не первый факап - та же RamBus для шин памяти, как она старалась при создании P4 архитектуры пересадить всех на RamBUS с i820 серией материнских чипов.
правда амд, via и sis не позволили свершиться надругательству :)
даже такая очепятка обычно приписывается при очередной проблеме у ВИнтел платформы - ШТЕУД снова отжёг.
Так-то винда первая из популярных декстопных систем, которая начала полноценную поддержку арм и "прозрачной" эмуляции там х86
Да и в целом Microsoft всегда была за совместимость: тот же dotnet делался чтобы не забивать себе голову какая там именно архитектура у ЦПУ; а ещё UWP вообще стёрла разницу между мобильной и дектопной ОС - пока апол даже не могла добиться совместимости даже между своим 6 и 10 айфонами с одинаковыми процессорами
полноценную поддержку арм
ахахахахахахахах
я просто напомню что в arm винде совершенно не было софта до емнип 2021 года, они даже свой собственный офисный пакет осилили собрать под arm вот недавно. да и по сей день в arm винде нечего ловить, тогда как под linux большинство софта есть под aarch64, ну и яблоки там чёт догнать пытаются (правда на костылях в виде ретрансляции x86 запросов в arm).
dotnet ужасен, да и практически мёртв за пределами одной, далеко не самой лучшей, платформы. UWP не стёрло разцины между десктопом и мобилой, UWP пытается превратить десктоп в мобилу (а ещё UWP совсем мертво за пределами масдая так что в серьёз не рассматривается даже если перестанет быть какашкой). если хотите пример вменяемого фреймворка созданного стереть границы между мобильным и десктопным миром посмотрите на kirigami.
dotnet ужасен, да и практически мёртв за пределами одной, далеко не самой лучшей, платформы.
сейчас набегут адепты C# со словами что в линухе он давно и успешно работает
у вас явно устарели знания про дотнет
UWP не стёрло разцины между десктопом и мобилой, UWP пытается превратить десктоп в мобилу
разве эту движуху не эппл начал и сам же не потянул, а MS попытались и тоже нет?
вообше насколько я вижу попытки превратить десктоп в мобилу прекратились... о сих пор помню странную тач менюшку настроек в фаерфоксе которую довольно быстро закопали ибо бред какойто
У вас слишком предвзятое мнение. Минимально полноценный 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 можно было размещать окна приложений по всей комнате + иметь полную иммерсивность управляя с помощью просто рук и глаз.
У вас слишком предвзятое мнение. Минимально полноценный office уже в 2012 был социально доступен под arm на винде.
разве, или вы это "блокнот" так нежно обозвали "минимально полноценный", это вообще взаимоисключающие слова..
выкатили бесшовный эмулятор x86 в arm
это называется свернули не туда, сейчас apple на те же грабли наступил
Dotnet живёт вообще везде, в том числе куча линуксовых серверов крутят приложения на dotnet. А если для вас он ужасен, то что лучше? У dotnet из прямых конкурентов только более тормозная джава.
ахаха, без коментариев))
Kirigami это какой-то нонейм мертвый за пределами обычного мобильного андроида (то есть форка линукса) и декстопного линукса? Тот же UWP гораздо известнее и не был ограничен только мобилками и плоскими мониторами декстопа, а так же работает на игровых консолях и даже в Mixed Reality. А на декстоп UWP наконец-то принесла ограниченный жизненный цикл приложений - то есть приложение не будет плодить тонны мусора в автозагрузке и в фоновом режиме есть кучу ресурсов в пустую потому что его разработчики так захотели. В итоге на ноутбуках и планшетах был сильный выигрыш по автономной работе. Да и на стационарных компах не приходилось докупать ОЗУ вагонами. А к мобиле модно было подключить монитор и получить декстопный гуй в приложениях. А в Mixed Reality можно было размещать окна приложений по всей комнате + иметь полную иммерсивность управляя с помощью просто рук и глаз.
а вы точно не в выдуманном мире живёте?
kirigami жизнеспособен на любой платформе с графикой, и винде, и линуксе и прочих (разве что кроме ios, но там в целом всё плохо с выбором фреймворков), просто пока не очень популярен (ну камон, ему безгоду неделя). и при этом он не пытается превратить десктоп в мобилу как UWP, и не пытается превратить мобилу в десктоп, он просто удобен и там и там.
UWP работает на консолях.. ну я рад за него, но это не делает его менее ужасным..
докупать ОЗУ тоннами.. так мы вроде не про браузеры речь ведём, а кроме браузеров сейчас на десктопе только телега любит по памяти утекать, ну и всякие dotnet и java поделия.
только более тормозная джава.
.....
ну и всякие dotnet и java поделия.
Вы явно не в курсе насколько ява проникла в айти и насколько она влияет на все в нашей жизни, и дотнет - созданный по её образу и подобию пытается в эту сферу тоже
и учитывая что вы считаете что ява тормозит...это смешно конечно ;)
вы на сях наверное пишите?
Скажем так, мне исходная концепция Java нравилась больше: вызовы к стандартным библиотекам почти сразу, или вообще сразу, уходили в нативный код и дальше в ОС. А начиная с версии 1.2 началось рисование средствами самой Java и это и правда было страшным тормозом. Просто я примерно в то время начал работать с Java и прочувствовал разницу. Сейчас, после того, как сильно накрутили JIT-компиляцию, стало куда интереснее, хотя ту, старую, концепцию очень жалко. Ну да, я в то время одновременно писал на Java и на C++, так что разница была весьма ощутимой. Не знаю, как дела в Java сейчас.
это называется свернули не туда, сейчас apple на те же грабли наступил
А почему не туда? Можно подробности?
Как пользователю - отлично, старые приложения работают, как работали, а новые работают быстрее.
растянули этап переезда до бесконечности..
Apple перешла на intel в 2005 (OS X 10.4) и откалась от поддержки power pc в 2009 (OS X 10.6), я думаю что и в этот раз длительность "бесконечности" будет недолгой
сложно прогнозировать
с одной стороны раньше софта было меньше и он был "попроще", с другой стороны сейчас для портирования часто вообще не надо ничего делать кроме как просто собрать те же исходники под другую архитектуру (да, далеко не всегда всё так просто, но в случае aarch64 больше половины зависимостей были подготовлены к портированию задолго до того как в apple вообще узнали что такое ARM).
к тому же сейчас всё чаще слышишь от разрабов что "бизнес решил что выгоднее пойти более быстрым пусть и неправильным путём"..
да и по сей день в arm винде нечего ловить
Вот из свежей дискуссии на RSDN:
>> Под нее давно и регулярно [url=https://www.xda-developers.com/windows-arm-apps/]выпускаются сборки популярного софта[/url] (Photoshop/Lightroom, MS Office, Firefox, GIMP, VLC, Spotify, Netflix, Zoom, FAR, 7-Zip, PassMark, Python, Go, Node.js, VS 2022, VS Code, CMake, OpenVPN, SysInternals Suite), много мелкого софта, [url=https://www.pcgamingwiki.com/wiki/List_of_Windows_ARM_games]больше сотни игрушек[/url].
Я бы не сказал, что это "нечего ловить". Жизнь простого юзера без особых бизнес-приложений уже обеспечена.
штомш, я на год отстал от жизни, видимо арм винда вышла из стадии "ос без софта" и перешла в стадию "такая же кривота как и на x86".
но судя по нагугленному окромя фотошопа (действительно не знал что его наконец-то собрали под aarch64) почти всё опсосные софтины которые как я и писал выше под aarch64 на linux есть уже оооооочень давно. ну зум не опсосный, но под линукс на арм он тоже давно уже был.
C# и .Net делались потому, что MS поссорилась с Sun и не потащила в Windows новую на тот момент версию Java. Я как раз тогда начал работать с Java и обратил внимание, что если хотеть кроссплатформенности, то надо ограничиваться версией 1.1, иначе программа вместо нескольких килобайт начинает занимать несколько мегабайт, потому что... Да, потому что надо ставить Java 1.2, а по тем временам это было ну очень много. Вот прямо не сравнить с Java 1.1, которая, к тому же, до какого-то момента даже шла в комплекте с Windows, да и сама была очень компактной и была идеальным воплощением идеи, потому что все вызовы сразу передавались на уровень хост-системы, а не как в более поздних версиях, где куча рисования делалась библиотеками на Java, то есть в интерпретаторе байт-кода. И вот в MS решили сделать свою "Java", громко завывая про кроссплатформенность. Вот только ни под что, кроме Windows это чудо не выпускалось. Ну правда, зачем? Заявили же, что кроссплатформенное, а сами реализовывать? Да на фиг! Я всё это лично видел и лично об это спотыкался.
Ну, технически, кросплатформенность у них была — прсото все эти платформы были из Win-семейства. А потом уже и .net core подтянулся
Года три назад ко мне подкатил заказчик, обещал "золотые горы", потом, правда, пропал без следа. Так вот, надо было ему на C# писать и я начал разбираться, как это нынче выглядит. А выглядело это, прямо скажем, весьма печально. Кажется, чуть ли не руками надо было в систему распаковывать эту самую "корочку" и даже включать всё это чудовище в проект, запаковывая в исполняемый файл. Получались очень маленькие ""Hello, world!", всего по 70-80 мегабайт каждый. То есть в два раза больше, чем развёрнутая Windows95. То есть да, можно и так. Или можно просто ставить ОС в виртуалку и запускать её как исполняемый файл. Ненуачо? И так для каждой мелкой программы. Java, с точки зрения пользователя Linux, выглядит куда интереснее: ставлю Eclipse - автоматом ставится Java, ставлю ещё что-то - ставится уже только вот это "что-то". А если на C#, если только не собирается с mono, всё вот так "весело".
У нас бинарники проекта на core, с зависимостями, занимают 28МБ. .net — системный.
Никого никуда не надо включать, запаковывать, оборачивать — там даже расширение файлов — dll; dotnet все делает сам.
Заказчик пропал без следа потому что понял что после ваших "начал разбираться" вы ничего не поняли.
Ох уж эти профессионалы, которые "начали разбираться"...
Вообще-то, он изначально знал, что с этим языкомя знаком поверхностно и с очень старой версией. Собственно, начали работать на другом языке с перспективой перехода на C#, потому что профильные клиентские библиотеки для работы API по большей части написаны именно на нём. При этом, у меня большой опыт работы с родственными языками - C, C++, Java, как и и общий стаж программирования. То есть я бы, продолжая работать над той задачей, над которой начал работать, за неделю-две подтянул бы знания по C# до приемлемого уровня, а дальше уже остаётся поиск по стандартным библиотекам, которые полностью всё равно никто не знает, удовлетворяясь той частью, которую используют постоянно.
Была и еще одна сложность — сложности с компилятором. Так, в программном
коде было очень непросто выявлять независимые по данным команды для
выполнения на VLIW-машине. Слишком много NOP-команд оказывалось в
результате в связках (bundles) сверхдлинного слова. Эту проблему,
насколько можно судить, изначально недооценили, а потом уже было поздно
что-то менять.
Это сложности не с компилятором, если имеется в виду что компилятор плохо компилирует. Это проблема любых VLIW, что для оптимальной компиляции для них нужны данные профилировки на типовых данных/операциях. Иначе компилятор не знает в какую сторону оптимизировать. Расставлять подсказки для компилятора вручную - тяжело, мало кто этим занимается (вы могли заметить макросы likely/unlikely в некотором коде, но это не распространено повсеместно). Некоторые разработчики добавляют перекомпиляцию по профилю собранному на типовых данных, но это тоже редкость.
В свой проект в качестве исследования решил поставить директивы likely/unlikely в условиях и операциях ветвления. Посмотрю что из этого выйдет.
Зависит от архитектуры, и "горячести" кода в который вы будете расставлять эти хинты для компилятора. Использование -fprofile-generate/-fprofile-use даст компилятору те же данные по всему коду (что был использован при профилировании). Скорее всего вы ничего не заметите. Для x86 это результаты в пределах погрешности, потому что погрешность высокая когда процессор может менять частоту.
Это проблема любых VLIW, что для оптимальной компиляции для них нужны данные профилировки на типовых данных/операциях.
1) Лучше говорить EPIC. VLIW это более широкое понятие.
2) Профилировка не сильно поможет при непредсказуемых задержках DRAM в сотни тактов.
Itanium Sales Forecasts
"Кем вы видите себя через пять лет?"
А мне одному кажется странным, что выходец из седой древности m68k до сих пор поддерживается, а Itanium, на котором делали Hi-End серверы (можно даже сказать, мейнфреймы), типа никому не нужен?
ну далеко не многие в свое время упоролись с переходом на итаниум (и как выяснилось не прогадали)
Это понятно. Но неужели есть кто-то, реально использующий Linux на m68k? Даже в области embedded такое трудно вообразить.
а причем тут линукс, вопрос лишь в оборудовании и софте для него, ОС тут значения особого не имеет.
видимо под m68k больше специализированного софта который никто не будет никогда переписывать под другие платформы, вот его и тянут...тут логика примерно такаяже как с выпуском 386/486 процессоров которые до 2007 года выпускались
и на итаниум, который понятно было что помрет уже во второй его версии видимо даже и не начали ничего серьезного переписывать
На Итаниумах (под ОС HP-UX правда, не Linux) работали особо большие на тот момент БД Oracle (лично их админил) и серверы приложений WebLogic. Базы уровня "биллинг крупного телекома".
Я бы не назвал ситуацию "ничего серьёзного не стали переписывать". И миграция этих баз с Itanium (миграция, к слову, тоже не на x86) была довольно-таки изысканным наслаждением.
Вот потому и интересны примеры такого уникального софта для m68k, потому что пример большого энтерпрайзного софта под Итаниум мне известен и я его привёл.
ну с ораклом всё ясно, там на спарк еще переезжали, но вообще это всётаки БД и юникс это слой совместимости, конкретно про m68k у меня примеров нет, но могу догадаться что это промышленные контроллеры, медицинские аппараты типа МРТ и прочее УЗИ, станки всякие... это всё крайне консервативные отрасли и там никто не будет софт менять если сегодня другой процессор модным станет
у меня помню на работе был станок который работал под Windows 95, в середине нулевых его по многочисленным просьбам радиослушателей портировали официально аж на Windows 98! и разработчики просто делали квадратные глаза и говорили что "всё отлично работает, вот комп, вот софт. в требованиях винда, чё тебе собака надо?" (c) ... станок лямов 50 стоил тогда... все запросы переделать софт хотябы на XP они просто отметали... причем софт был написан на VB5 (рукалицо) и под NT системами упорно не работал никак из-за того что гвоздями был прибит ф-циям ядра 9x винды
В embedded продолжают производить m68k based SoC и кто-то поддерживает Linux на них. Это уже легаси, да - иначе бы взяли что-то стиля STM32. Но есть.
Цитирую свой старый комментарий:
=== cut here ===
Пусть у вас пачка из нескольких команд — фиксированно и немного (Itanium — группами по 3 команды, количество групп прямо не ограничено), или нефиксированно и много (Эльбрус-4 — до 30). Какая-то часть из них кодирует операции только с регистрами — считаем, они доступны всегда, и на чтение и на запись. Какая-то обращается к памяти. Вот тут начинаются проблемы. Если у вас обыкновенная DRAM, у неё самая длительная операция это закрыть неактуальную строку (переписать из её кэша, который в самой микросхеме DRAM, в собственно DRAM-часть) и открыть заказанную (прочитать и переписать в тот кэш на борту DRAM). Эта операция в лучших представителях занимает около 25 нс, в "бюджетных" DDR4 до 40 нс. (Обозначается обычно tRAS или похоже.) В тактах процессора... ну умножьте на 4, если у него 4ГГц тактовая. А ещё надо добавить время на опознание, что данных нет ни в одном локальном кэше (обычно добавляется где-то до 30 тактов), нет ни у одного партнёра по SMP (может быть и ~50 тактов) и на чтение полной строки (64 байта на x86) из DRAM (ну, ещё десятка два тактов, там высокая параллельность) — спокойно можно добрать и до 300 тактов.
Это чрезвычайно высокая цифра, даже если сравнивать с супердорогими арифметическими операциями типа деления (128/64 на x86, считается, до 90 тактов).
Теперь представим себе поток команд. На x86 вполне может быть, что пока 30-я по
счёту только-только прочиталась из памяти, 25-я раскодирована, 20-й назначили все внутренние регистры и она ждёт выполнения, 15-я выполняется, 10-я закончила и
результаты готовы, но ждёт, пока предыдущие завершат операции, результат 7-й сидит во write queue на выходе в кэш, для 5-й заканчивают синхронизацию между кэшам
и в SMP, 1-я наконец всё типа закончила (слила результат в кэш в строку, которая
эксклюзивно принадлежит на запись текущему ядру). В это время 2-я задумчиво занимается делением, и её результаты будут ещё тактов через 40. Но она (2-я) пишет
в регистр, поэтому не тормозит заметную остальных; её результаты будут применены только к 15-й команде, а результаты той — только к 24-й, поэтому с остальными можно работать. Я не преувеличиваю в цифрах — у Skylake, например, цепочка от "наконец заканчиваем, фиксируем результаты" до "выбрали, начинаем декодировать" может быть до 224 микроопераций.
Процессор сам вычисляет, какая команда от какой зависит. Есть очевидные зависимости по регистрам (типа, если 3-я записала в eax, а 5-я его читает, 5-я должна выполняться после 3-й). Есть зависимости по памяти (x86 настаивает на том, что все операции записи в память упорядочены по этим действиям записи — хотя вычисления в них не требуют такой зависимости). Получается такой себе DAG исполнений, внутри которого заметная свобода.
А теперь чем отличается EPIC? Само название: Explicitly parallel instruction computing. Параллельность рассчитана на этапе написания машинного кода (обычно — компилятором). Причём не в терминах "данная команда хочет результаты той, что на 1
5 раньше по цепочке" — такое бы требовало слишком много места для записи — а в виде группировок типа "данные команды друг на друга не влияют" (см. ниже), "можно параллелить сколько угодно по вкусу" и "а вот тут мы знаем явную зависимость, надо завершить все предыдущие до всех последующих". В доке по Itanium это выглядит так:
>> An instruction group is a sequence of instructions starting at a given bundle
address and slot number and including all instructions at sequentially increasing slot numbers and bundle addresses up to the first stop, taken branch, Break Instruction fault due to a break.b, or Illegal Operation fault due to a Reserved or Reserved if PR[qp] is one encoding in the B-type opcode space. For the instructions in an instruction group to have well-defined behavior, they must meet the ordering and dependency requirements described below.
и вот главные слова — "must meet the ordering and dependency requirements". Автору машкода надо явно определить группы, в которых взаимовлияние минимизировано,
и зафиксировать их. Дальше в доке много страшных слов, но вот одни из ключевых:
>> Between instruction groups, every instruction in a given instruction group will behave as though its read occurred after the update of all the instructions from the previous instruction group.
Процессор не имеет права посчитать, что какая-то команда из IG1 может быть выполнена одновременно с какой-то последующей IG2, если между ними стоит явный stop. Даже прочесть данные из памяти в регистр — потому что это называется update of architectural state. Память тормозит? Жди.
>> Within an instruction group, every instruction will behave as though its read of the register state occurred before the update of the register state by any instruction (prior or later) in that instruction group, except as noted in the Register dependencies and Memory dependencies described below.
[...]
>> Register dependencies: Within an instruction group, read-after-write (RAW) and write-after-write (WAW) register dependencies are not allowed (except пара незначительных исключений)
А это, наоборот, в одной группе не может быть зависимостей (как уже сказал — надо отбирать только независимые действия). Хотел исхитриться и применить результаты чтения сразу же? Обломись, бабка, мы на корабле.
Дальше в доке много чего — 100500 поправок, уточнений и исключений, словно специально, чтобы запутать всех и усложнить компилятор до предела. Но смысл основной тот же: пока на тех архитектурах, где процессор вычисляет зависимости на ходу (как x86), одна команда не тормозит соседних "товарок", пока её результаты не нужны, и может быть выделена из основного потока — на IA-64 такой свободы нет, учись предсказывать задержки по памяти — то, чего в принципе предсказать невозможно на обычном современном железе (если вы не занимаетесь Meltdownʼом).
Резонный вопрос — а почему вообще Intel решил, что возможно такую архитектуру сделать эффективной? А вот тут надо заглянуть в историю и заметить, что тогда же его топ-менеджмент попался на две удочки одновременно — первая под названием Rambus, а вторая — NetBurst (Pentium 4 должен был по тем планам стать последним x86). Супербыстрая DRAM плюс ориентация на потоковые SIMD действия (для "мультимедиа") и пренебрежение всеми остальными классами задач. Чем тут поможет SIMD? А именно тем, что для основных задач хорошо предсказывается необходимость подчитать память — можно заранее (на одну-две IG) сказать prefetch на нужный кусок, пока выполняются предыдущие, оно уже в L1. Но тут наступил облом — не стала мультимедия единственным использованием компьютера, а Rambus мало того, что выпустила память с бо́льшими задержками, так и оказалось, что все новомодные усовершенствования это фикция, а заодно патентный буллинг (Intel потеряла ок. 4e8$$, насколько помню).
Так что EPIC эффективен только там, где вы можете строго ограничить время одной даже самой длительной команды. Видимо, из подобных соображений Intel исключил из IA-64 простое целочисленное деление — он знал, что это долго, но "не знал" того же про чтение DRAM. Если у вас SRAM (умножьте цену памяти на 10-20) — ok, вперёд. Если у вас DSP (тоже, считаем, SRAM) — тоже пойдёт, туда подобные архитектуры внедрились и устоялись. Но для "обычного" современного компа, для толстого сервера — ой, зась.
И вслед этому очевидный вопрос про "импортозаместительный" Эльбрус-4. На синтетических тестах он много чего показывает, но про реальные задачи идёт много подпольных отзывов про жуткие тормоза...
=== end cut ===
Процессор Itanium и архитектура IA-64 окончательно забыты: в ядре Linux 6.7 их код удаляют. Что пошло не так с Itanium?