Ответ 1
Itanium потерпел неудачу, потому что VLIW для сегодняшних рабочих нагрузок - просто ужасная идея.
Дональд Кнут, широко уважаемый ученый-компьютерщик, сказал в интервью 2008 года, что "подход Itanium" должен был быть настолько потрясающим - до тех пор, пока не оказалось, что желаемые компиляторы практически невозможно написать ". 1
Это в значительной степени обостряет проблему.
Для научных вычислений, где вы получаете как минимум несколько десятков инструкций на базовый блок, VLIW, вероятно, работает нормально. Там достаточно инструкций, чтобы создать хорошие связки. Для более современных рабочих нагрузок, где часто вы получаете около 6-7 инструкций на базовый блок, это просто не так (в среднем, IIRC для SPEC2000). Компилятор просто не может найти независимые инструкции для включения в пакеты.
Современные процессоры x86, за исключением Intel Atom (до Silvermont) и, как мне кажется, AMD E-3 **/4 **, являются процессорами не по порядку. Они поддерживают динамическое окно команд примерно из 100 команд, и в этом окне они выполняют инструкции, когда их входные данные становятся готовыми. Если несколько инструкций готовы к выполнению и они не конкурируют за ресурсы, они объединяются в одном цикле.
Так чем же это отличается от VLIW? Первое ключевое отличие между VLIW и неупорядоченным состоянием состоит в том, что процессор неупорядоченного порядка может выбирать команды из разных базовых блоков для одновременного выполнения. Эти инструкции в любом случае выполняются спекулятивно (прежде всего на основе прогнозирования ветвлений). Второе ключевое отличие состоит в том, что процессоры, вышедшие из строя, определяют эти расписания динамически (т.е. Каждая динамическая инструкция планируется независимо; компилятор VLIW работает со статическими инструкциями).
Третье ключевое отличие состоит в том, что реализации процессоров, вышедших из строя, могут быть настолько широкими, насколько это необходимо, без изменения набора команд (Intel Core имеет 5 портов выполнения, другие процессоры имеют 4 и т.д.). Машины VLIW могут выполнять несколько пакетов одновременно (если они не конфликтуют). Например, ранние процессоры Itanium выполняют до 2 пакетов VLIW за такт, 6 инструкций, а в более поздних версиях (2011 Poulson и более поздние версии) выполняется до 4 пакетов = 12 инструкций за такт, при этом SMT принимает эти инструкции из нескольких потоков. В этом отношении реальное аппаратное обеспечение Itanium похоже на традиционный суперскалярный дизайн в порядке (например, P5 Pentium или Atom), но с более/более эффективными способами для компилятора выставлять параллелизм на уровне команд аппаратному обеспечению (теоретически, если он может найти достаточно, в чем проблема).
По производительности с похожими характеристиками (кеш, ядро и т.д.) Они просто выбивают дерьмо из Itanium.
Так почему бы купить Itanium сейчас? Ну, единственная причина действительно HP-UX. Если вы хотите запустить HP-UX, то способ сделать это...
Многие авторы компиляторов не видят этого таким образом - им всегда нравился тот факт, что Itanium дает им больше возможностей, возвращает их к контролю и т.д. Но они не признают, насколько неудачно это произошло.
Сноска 1:
Это было частью ответа о ценности многоядерных процессоров. Кнут говорил, что параллельной обработкой трудно воспользоваться; Нахождение и разоблачение детализированного параллелизма на уровне команд (и явное предположение: EPIC) во время компиляции для VLIW также представляет собой сложную проблему, которая в некоторой степени связана с нахождением крупнозернистого параллелизма для разделения последовательной программы или функции на несколько потоков для автоматического воспользоваться несколькими ядрами.
Спустя 11 лет он все еще в основном прав: производительность для каждого потока все еще очень важна для большинства несерверного программного обеспечения, и на чем сосредоточены производители ЦП, потому что многие ядра не заменяют его.