Почему процессору Itanium было сложно написать компилятор?

Обычно утверждается, что архитектура 64-разрядных процессоров Intel Itanium не удалась, потому что для революционного набора команд EPIC было очень сложно написать хороший компилятор, что означало отсутствие хороших инструментов разработчика для IA64, что означало отсутствие разработчиков, создающих программы для архитектуры. и поэтому никто не хотел использовать аппаратное обеспечение без большого количества программного обеспечения для него, и поэтому платформа вышла из строя, и все из-за недостаткаподковообразный гвоздь хорошие компиляторы.

Но почему компилятор был такой сложной технической проблемой? Мне кажется, что если поставщикам компиляторов было трудно реализовать явный параллелизм в EPIC ... зачем в первую очередь возлагать на них это бремя? Это не похоже на то, что хорошего, хорошо понятого решения этой проблемы еще не было: вместо этого возложите эту нагрузку на Intel и дайте авторам компиляторов более простую цель.

Itanium появился в 1997 году. К этому моменту системе байт - кода UCSD P-Code было около 20 лет, Z-машина немного моложе, а JVM стала горячей новой восходящей звездой в мире языков программирования. Есть ли какая-то причина, по которой Intel не указала язык «простого байт-кода Itanium» и не предоставила инструмент, который преобразует этот байт-код в оптимизированный код EPIC, используя свой опыт в первую очередь для разработчиков системы?

Как я помню в то время, проблема заключалась не только в особенностях IA64, но и в конкуренции с набором инструкций AMD x86-64. Сделав свою архитектуру обратно совместимой с набором команд x86, AMD смогла использовать существующие инструменты и наборы навыков разработчиков. Движение AMD было настолько успешным, что Intel (и Via) были вынуждены принять архитектуру x86-64.

Большим препятствием на тот момент было 4 ГБ ОЗУ на настольных ПК (более реалистично - 3,4 ГБ, которые можно использовать в Windows). x86-64 преодолел этот барьер и открыл для всех более мощные вычисления. Если бы AMD никогда не предлагала x86-64, я уверен, что Intel была бы счастлива, если бы каждый, кто хотел перейти на 4 ГБ + ОЗУ, заплатил бы немалую премию за эти привилегии в течение многих лет. Чтобы продемонстрировать, как медленно движутся рынки, приложениям потребовались годы, чтобы перехватить до 64-битное многопоточное программирование, и даже сейчас 4 ГБ ОЗУ является стандартом для недорогих ПК.

Короче говоря, Intel попыталась совершить революционный скачок с архитектурой IA64, а AMD сделала эволюционный шаг с x86-64. На устоявшемся рынке эволюционные шаги, позволяющие работникам умственного труда использовать имеющиеся навыки, одержат победу над революционными шагами, которые требуют от всех новых навыков. Несмотря на качественные различия между архитектурами, IA64 не смог преодолеть импульс собственной платформы x86 после того, как AMD добавила расширения x86-64.

Я не покупаю объяснение, что IA64 было слишком сложно для программирования. Это было только трудно по отношению к альтернативам. Идея @ delnan о низкоуровневом инфракрасном излучении не имеет смысла, я просто не думаю, что это имело бы значение.

А почему Intel не пыталась взять на себя это бремя, кто знает? Они были рыночной властью в то время. AMD была чем-то вроде угрозы, но Intel была королем холма. Возможно, они думали, что IA64 будет намного лучше, чем что-либо еще, что они могли бы сдвинуть весь рынок. Возможно, они пытались создать премиальный уровень и оставить AMD, VIA и т. Д. Во втором уровне, сражаясь за низкомаржинальное товарное оборудование - стратегию, которую Intel и Apple использовали довольно успешно.

Было ли Itanium преднамеренной попыткой создать платформу премиум-класса и вытащить коврик из-под AMD, VIA и т. Д.? Конечно, так работает бизнес.

Статья Википедии на EPIC уже наметила много опасностей , общих для VLIW и EPIC.

Если кто-то не уловил чувства фатализма из этой статьи, позвольте мне подчеркнуть это:

Ответы загрузки из иерархии памяти, которая включает в себя кэши ЦП и DRAM, не имеют детерминированной задержки.

Другими словами, любая аппаратная конструкция, которая не справляется с (*) недетерминированной задержкой при доступе к памяти, просто станет впечатляющим провалом.

(*) Чтобы справиться с необходимостью, необходимо добиться достаточно хорошей производительности выполнения (иными словами, «конкурентоспособной по стоимости»), что исключает необходимость частого простоя процессора в течение десятков или сотен циклов.

Обратите внимание, что стратегия преодоления, используемая EPIC (упомянутая в статье в Википедии, ссылки на которую приведены выше), фактически не решает проблему. Это просто говорит о том, что бремя указания зависимости данных теперь ложится на компилятор. Все в порядке; компилятор уже имеет эту информацию, поэтому компилятору просто выполнить его. Проблема в том, что процессор все еще будет простаивать в течение десятков или сотен циклов при обращении к памяти. Другими словами, он экстернализует вторичную ответственность, но по-прежнему не справляется с основной ответственностью.

Вопрос можно перефразировать следующим образом: «Учитывая аппаратную платформу, которая обречена на провал, почему (1) не (2) не могли авторы компилятора героически приложить усилия, чтобы выкупить ее?»

Я надеюсь, что мое перефразирование сделает ответ на этот вопрос очевидным.

Существует второй аспект неудачи, который также является фатальным.

Стратегии копирования (упомянутые в той же статье) предполагают, что программная предварительная выборка может использоваться для восстановления хотя бы части потери производительности из-за недетерминированной задержки при доступе к памяти.

В действительности, предварительная выборка выгодна, только если вы выполняете потоковые операции (чтение памяти последовательным или очень предсказуемым образом).

(Тем не менее, если ваш код делает частый доступ к некоторым локализованным областям памяти, кэширование поможет.)

Тем не менее, большинство универсального программного обеспечения должно иметь много случайных обращений к памяти. Если мы рассмотрим следующие шаги:

• Рассчитайте адрес, а затем
• Прочитайте значение, а затем
• Используйте это в некоторых расчетах

Для большинства универсального программного обеспечения эти три должны выполняться в быстрой последовательности. Другими словами, не всегда возможно (в рамках логики программного обеспечения) рассчитать адрес заранее или найти достаточно работы, чтобы заполнить ларьки между этими тремя шагами.

Чтобы объяснить, почему не всегда можно найти достаточно работы, чтобы заполнить киоски, вот как можно это визуализировать.

• Допустим, чтобы эффективно скрывать киоски, нам нужно заполнить 100 инструкций, которые не зависят от памяти (поэтому не будут страдать от дополнительной задержки).
• Теперь, как программист, пожалуйста, загрузите любое программное обеспечение по вашему выбору в дизассемблер. Выберите случайную функцию для анализа.
• Можете ли вы определить где-нибудь последовательность из 100 инструкций (*), которые не имеют доступа к памяти?

(*) Если бы мы могли сделать NOPполезную работу ...

Современные процессоры пытаются справиться с тем же, используя динамическую информацию - одновременно отслеживая ход выполнения каждой инструкции по мере ее передачи по конвейерам. Как я упоминал выше, часть этой динамической информации обусловлена ​​недетерминированной задержкой памяти, поэтому компиляторы не могут предсказать ее с какой-либо степенью точности. В общем, во время компиляции просто недостаточно информации для принятия решений, которые могли бы заполнить эти киоски.

В ответ на ответ А.П.Программер

Дело не в том, что «компилятор ... извлекать параллелизм сложно».

Переупорядочение памяти и арифметических инструкций современными компиляторами свидетельствует о том, что у него нет проблем с идентификацией операций, которые независимо и, следовательно, выполняются одновременно.

Основная проблема заключается в том, что недетерминированная задержка памяти означает, что любая «пара сопряжения», закодированная для процессора VLIW / EPIC, в конечном итоге будет остановлена ​​доступом к памяти.

Оптимизация инструкций, которые не блокируются (только регистр, арифметика), не помогут с проблемами производительности, вызванными инструкциями, которые с большой вероятностью блокируются (доступ к памяти).

Это пример отказа от применения правила 80-20 оптимизации: оптимизация уже быстрой работы не приведет к значительному улучшению общей производительности, если не оптимизировать более медленную.

В ответ на ответ Василия Старынкевича

Это не «... (что бы то ни было) трудно», это то, что EPIC не подходит для любой платформы, которая должна справляться с высоким динамизмом в задержке.

Например, если процессор имеет все следующее:

• Нет прямого доступа к памяти;
  • Любой доступ к памяти (чтение или запись) должен быть запланирован с помощью передачи DMA;
• Каждая инструкция имеет одинаковую задержку выполнения;
• Выполнение заказа;
• Широкие / векторизованные исполнительные блоки;

Тогда VLIW / EPIC подойдет.

Где найти такие процессоры? DSP. И здесь процветал VLIW.

Оглядываясь назад, неудача Itanium (и продолжающиеся усилия по НИОКР в неудачу, несмотря на очевидные доказательства) является примером организационной неудачи и заслуживает глубокого изучения.

Конечно, другие проекты вендора, такие как гиперпоточность, SIMD и т. Д., Кажутся весьма успешными. Вполне возможно, что инвестиции в Itanium могли оказать благотворное влияние на навыки его инженеров, что, возможно, позволило им создать успешную технологию следующего поколения.

TL; DR: 1 / есть другие аспекты отказа Itanium, кроме проблем компилятора, и их вполне может быть достаточно, чтобы объяснить это; 2 / байт-код не решил бы проблемы компилятора.

Обычно утверждается, что архитектура 64-разрядного процессора Intel Itanium не сработала, потому что революционный набор команд EPIC было очень сложно написать хороший компилятор для

Ну, они также опоздали (запланировано на 98 год, первая отгрузка в 2001 году), и когда они наконец доставили оборудование, я даже не уверен, что оно доставило то, что было обещано на более раннюю дату (IIRC, они по крайней мере отбросили часть Эмуляция x86, которая была изначально запланирована), поэтому я не уверен, что даже если бы проблемы с компиляцией были решены (и AFAIK, пока нет), они бы преуспели. Компилятор не был единственным аспектом, который был слишком амбициозным.

Есть ли какая-то причина, по которой Intel не указала язык «простого байт-кода Itanium» и не предоставила инструмент, который преобразует этот байт-код в оптимизированный код EPIC, используя свой опыт в первую очередь для разработчиков системы?

Я не уверен, где вы разместите инструмент.

Если он находится в процессоре, у вас есть просто другая микроархитектура, и нет никаких причин не использовать x86 в качестве общедоступного ISA (по крайней мере, для Intel несовместимость дороже, чем то, что может принести более чистый общедоступный ISA).

Если это внешне, то, начиная с байт-кода, сделать это еще сложнее, чем начинать с языка более высокого уровня. Проблема с EPIC заключается в том, что он может использовать только тот параллелизм, который может найти компилятор, и извлечь этот параллелизм сложно. Знание языковых правил дает вам больше возможностей, чем если вы ограничены чем-то уже запланированным. Мое (признанное ненадежным и от кого-то, кто следил за этим издалека) воспоминание о том, что HP (*) и Intel не смогли достичь на фронте компилятора, является извлечение параллелизма на уровне языка, а не низкий уровень, который был бы в байте код.

Возможно, вы недооцениваете стоимость, с которой современные процессоры достигают своей производительности. ООО эффективнее других возможностей, но, безусловно, неэффективно. EPIC хотела использовать бюджет области, использованный при реализации OOO, для обеспечения более необработанных вычислений, надеясь, что компиляторы смогут использовать его. Как написано выше, не только мы все еще не можем - как AFAIK, даже теоретически - писать компиляторы, обладающие такой способностью, но Itanium получил достаточно других сложных для реализации функций, что он опоздал, а его грубая мощность не даже конкурентоспособный (за исключением, возможно, на некоторых нишевых рынках с большим количеством вычислений FP) с другим высокопроизводительным процессором, когда он вышел из строя.

(*) Вы также, кажется, недооцениваете роль HP в EPIC.

Несколько вещей.

IPF был в порядке, например. Это означало, что вы не можете рассчитывать на повторный заказ, чтобы спасти вас в случае пропадания кэша или другого продолжительного события. В результате вам в конечном итоге пришлось полагаться на умозрительные функции, а именно на умозрительные нагрузки (нагрузки, которые были допущены к сбою - полезно, если вы не знали, нужен ли вам результат нагрузки), и расширенные нагрузки (нагрузки, которые могли быть перезапустите, используя код восстановления, если возникла опасность.) Правильно понять это было сложно, особенно сложные загрузки! Существовали также подсказки предварительной выборки ветки и кэша, которые действительно могли быть использованы только программистом на ассемблере или с использованием оптимизации на основе профилей, обычно не с традиционным компилятором.

Другие машины того времени - а именно UltraSPARC - были в порядке, но у IPF были и другие соображения. Одним из них было кодирование пространства. Инструкции Itanium были, по своей природе, не особенно плотными - 128-битный пакет содержал три операции и 5-битное поле шаблона, в котором описывались операции в пакете, и могли ли они все выпускаться вместе. Это обеспечило эффективный размер операции 42,6 бит - сравните с 32 битами для большинства коммерческих операций RISC в то время. (Это было до Thumb2 и др. - RISC по-прежнему означал жесткость с фиксированной длиной.) Еще хуже, у вас не всегда было достаточно ILP, чтобы соответствовать шаблону, который вы использовали, - поэтому вам понадобится NOP-pad для заполнения шаблон или комплект. Это, в сочетании с существующей относительной низкой плотностью, означало, что получение приличной скорости попадания в i-кеш было а) действительно важным,

Хотя я всегда чувствовал, что аргумент «компилятор был единственной проблемой» был преувеличен - существовали законные микроархитектурные проблемы, которые действительно не оказывали никакой пользы для общего кода - генерация кода для сравнения не была особенно интересной к более узким, высокоскоростным машинам OoO дня. Когда вы могли действительно правильно заполнить его, что часто требовало либо PGO, либо ручного кодирования, это было здорово - но в большинстве случаев производительность компиляторов была просто скучной. С помощью IPF было нелегко генерировать отличный код, и это было неумолимо, когда код был плохим.

Но почему компилятор был такой сложной технической проблемой? Мне кажется, что если поставщикам компиляторов было трудно реализовать явный параллелизм в EPIC ... зачем в первую очередь возлагать на них это бремя? Это не похоже на то, что хорошего, хорошо понятого решения этой проблемы еще не было: вместо этого возложите эту нагрузку на Intel и дайте авторам компиляторов более простую цель.

То, что вы описываете, немного напоминает то, что Transmeta пыталась сделать со своим программным обеспечением для преобразования кода (которое динамически переводило x86 «байт-код» во внутренний машинный код Transmeta).

Что касается того, почему Intel не удалось сделать достаточно хороший компилятор для IA64 ... Я полагаю, что у них не было достаточного опыта компиляторов в доме (даже если, конечно, у них были некоторые очень хорошие эксперты по компилятору внутри, но, вероятно, не достаточно, чтобы сделать критическую массу). Я думаю, что их руководство недооценило усилия, необходимые для создания компилятора.

AFAIK, Intel EPIC потерпел неудачу, потому что компиляция для EPIC действительно трудна, а также потому, что когда технология компилятора медленно и постепенно совершенствуется, другие конкуренты также могут улучшить свой компилятор (например, для AMD64), делясь некоторыми ноу-хау компилятора.

Кстати, я бы хотел, чтобы AMD64 был еще набором команд RISCy. Это мог быть POWERPC64 (но, вероятно, не из-за проблем с патентами, из-за требований Microsoft в то время и т. Д.). Архитектура набора команд x86-64 на самом деле не является «очень хорошей» архитектурой для разработчика компиляторов (но она как-то «достаточно хороша»).

Кроме того, архитектура IA64 имеет некоторые строгие ограничения, например, 3 инструкции / слова были хорошими, если у процессора было 3 функциональных блока для их обработки, но как только Intel перешла на более новые чипы IA64, они добавили больше функциональных блоков, а инструкция - Уровень параллелизма было еще раз трудно достичь.

Возможно, RISC-V (ISA с открытым исходным кодом) постепенно добьется успеха, чтобы сделать его конкурентоспособным по сравнению с другими процессорами.

Как указал Роберт Манн, именно отсутствие обратной совместимости убило Itanium (и многие другие «новые» технологии).

Хотя написать новый компилятор может быть сложно, вам нужно всего лишь несколько из них. Компилятор переменного тока, который производит оптимизированный код, является обязательным, иначе у вас не будет используемой операционной системы. Вам нужен компилятор C ++, Java и учитывая, что основной пользовательской базой будет Windows, своего рода Visual Basic. Так что это не было проблемой. Была приличная операционная система (NT) и хороший компилятор Си.

То, что для компании, предлагающей программный продукт, кажется тривиальным - перекомпилируйте и повторно протестируйте свою базу кода C (а в то время большинство из них были бы написаны на чистом C!) Было не так просто; Преобразование большого набора программ на Си, которые предполагали 32-битное целое число и 32-битную адресацию в 64-битную архитектуру, были полны ловушек. Если бы IA64 стал доминирующим чипом (или даже популярным!), Большинство софтверных компаний укушали бы пулю и приложили усилия.

Такой быстрый чип с разумной ОС, но с очень ограниченным набором доступного программного обеспечения, поэтому не многие покупали его, поэтому не многие компании-производители программного обеспечения предоставили продукты для него.

Itanium убили задержки с поставками, которые открыли дверь для AMD64, прежде чем поставщики программного обеспечения решили перейти на IA64 для 64-битных приложений.

Оставить оптимизацию для компилятора было хорошей идеей. Многое можно сделать статичным, что в противном случае неэффективно в аппаратном обеспечении. Компиляторы в этом преуспели, особенно при использовании профилирования PGO (я работал в HP, а компилятор HP имел тенденцию превосходить Intel). PGO был навязчивым товаром, однако это сложный процесс для производственного кода.

IPF должен был быть обратно совместимым, но как только AMD64 запустился, он стал спорным, битва была проиграна, и я считаю, что аппаратное обеспечение X86 в ЦП было просто разобрано для перенастройки в качестве серверного ЦП. Итаниум как архитектура не был плохим, 3 инструкции на слово не было проблемой. Проблема заключалась в реализации гиперпоточности путем замены стеков во время ввода-вывода памяти, который был слишком медленным (для очистки и перезагрузки конвейера) до Montecito и т. Д., Что не позволяло ему конкурировать с вышедшими из строя процессорами PowerPC. Компиляторам пришлось исправлять ошибки, связанные с поздним обнаружением реализаций ЦП, и некоторые преимущества производительности терялись из-за трудностей в прогнозировании ошибок.

Архитектура позволила Itanium быть относительно простым, предоставляя компилятору инструменты для извлечения из него производительности. Если бы платформа работала, процессоры стали бы более сложными, и в конечном итоге стали бы многопоточными, вышли из строя и т. Д., Как x86. Тем не менее, первые генераторы сосредоточили внимание на транзисторах на других схемах производительности, так как компилятор справился со многими сложными задачами.

Платформа IPF сделала ставку на компилятор и инструменты, и это была первая архитектура, которая представила чрезвычайно полную и мощную конструкцию Performance Monitoring Unit (PMU), которая позже была перенесена на Intel x86. Поэтому разработчики мощных инструментов до сих пор не используют его в полной мере для профилирования кода.

Если вы посмотрите на успехи ISA, то чаще всего это не техническая сторона игры в кости. Это его место во времени и рыночных силах. Посмотрите на SGI Mips, DEC Alpha ... Itanium только что был поддержан проигравшими, серверами SGI и HP, компаниями, которые руководили стратегическими бизнес-ошибками. Microsoft никогда не была полноценной и принимала AMD64, чтобы не играть в боксе только с Intel в качестве игрока, и Intel не стала правильно играть с AMD, чтобы дать им возможность жить в экосистеме, поскольку они намеревались уничтожить AMD.

Если вы посмотрите на то, где мы находимся сегодня, то сложное оборудование X86 до сих пор привело его в тупик эволюции. Мы застряли на частоте 3 + ГГц и выгружаем ядра с недостаточным использованием. Более простая конструкция Itanium привнесла бы больше усилий в компилятор (пространство для роста), что позволило бы создавать более тонкие и быстрые конвейеры. При том же поколении и потрясающей технологии, она работала бы быстрее и была бы такой же, но чуть выше, и, возможно, открылись бы другие двери, чтобы подтолкнуть закон Мура.

Ну, по крайней мере, выше, это мои убеждения :)

Память становится неясной ... У Itanium было несколько замечательных идей, которые требовали бы отличной поддержки компилятора. Проблема была в том, что это была не одна особенность, это было много. Каждый из них не имел большого значения, все вместе были.

Например, была функция зацикливания, при которой одна итерация цикла работала бы с регистрами из разных итераций. x86 решает ту же проблему с помощью огромных возможностей.

В то время Java и JVM были в моде. IBM сказала, что с PowerPC вы можете быстро скомпилировать байт-код, и процессор сделает это быстро. Не на Itanium.