Единственная очевидная загвоздка в подобном подходе - тот самый компилятор, умеющий генерировать очень сложный технически и требующий тщательнейшей оптимизации машинный код для VLIW-процессоров. Но ведь, в конце концов, и простые компиляторы с языков высокого уровня когда-то казались чудом, а сейчас мы преспокойно используем сложнейшие компиляторы C++, работающие с парадигмами обобщенного программирования. Так что создание совершенного оптимизирующего компилятора для VLIW-процессоров - это, скорее, вопрос времени[Отрадно, кстати, сознавать, что над созданием этих «суперкомпиляторов», в первую очередь - Intel C/C++ Compiler, активно работают наши соотечественники - например, Нижегородская лаборатория (бывшая московская команда Бориса Бабаяна, разрабатывавшая компиляторы для «Эльбруса Е2К»). Нам бы, правда, к этому еще и свои процессоры с компиляторами…]. Но есть и другие проблемы.
Проблема первая - жесткая привязка исполняемого кода к конкретному процессору. x86-программа запросто может работать и на i386, и на Pentium 4; с каноническим VLIW-процессором такой фокус, увы, не пройдет. Правда, Intel в усовершенствованной версии VLIW-архитектуры (EPIC - Explicitly Parallel Instruction Computer, компьютер с явно заданным параллелизмом команд) смягчила этот недостаток, введя не инструкции, а bundles - эдакие «полуинструкции», упакованные в контейнере с информацией о взаимозависимостях между этим и другими бандлами. Предполагается, что процессор, без труда проверив бандлы на взаимозависимость, может запускать их параллельно и, таким образом, обладать некоторой «свободой действий» в проектировании будущих CPU, сохраняющих бинарную совместимость с текущим поколением.
Вторая проблема прямо вытекает из первой: довольно трудно сделать совместимые VLIW-процессоры, предназначенные для разных секторов рынка. Уж больно сильно привязан программный код к аппаратной начинке. То есть если мы делаем «супер-VLIW», с кучей исполнительных устройств и тщательно вылизанной подсистемой памяти - то ровно такой же «суперпроцессор» (с суперсебестоимостью) нам придется продавать и для low-end-сектора рынка. И наоборот, «сэкономив» и выкатив процессор для low-end и middle-end, мы получим крепкого середнячка, но не лидера производительности. Подход EPIC с его бандлами слегка исправляет ситуацию, но не до конца - дешевых Itanium в природе так и не появилось.
Третий и, пожалуй, главный недостаток VLIW - это то, что предусмотреть и спланировать все события в процессоре невозможно. К примеру, нельзя предугадать, сколько времени займет операция обращения к оперативной памяти. А раз так, то нельзя и эффективно запланировать ее: OoO-исполнения во VLIW-процессорах не бывает, и если мы думали, что данные для инструкции в кэше будут, а их там не оказалось, то весь этот сложный, «мышцастый» процессор будет простаивать десятки и сотни тактов, дожидаясь исполнения злополучной инструкции загрузки данных. В EPIC придуман способ борьбы и с этой проблемой - программную предвыборку данных, software prefetch[Это такие специальные инструкции, которые позволяют процессору параллельно с основным исполнением запросить фоновую подгрузку в кэш-память определенных данных, если их там еще нет.]; однако подсистема памяти до сих пор остается одним из самых узких мест любого VLIW-процессора.
Идея VLIW отнюдь не нова - еще в середине 80-х годов корпорация Intel пыталась продвигать весьма неординарный VLIW-процессор i860. Однако описанные проблемы и отсутствие по-настоящему эффективных оптимизирующих компиляторов поставили крест на i860 еще до его практического рождения. Да, i860 был «суперкомпьютером на чипе», да, он опережал свое время, но как процессор общего назначения - никуда не годился[Теоретический максимум производительности - 60 Мфлопс. Практический максимум для программистов, вручную оптимизировавших код для i860 на ассемблере, - 40 Мфлопс. Производительность обычного компилятора для i860 - не более 10 Мфлопс. Производительность рабочих станций на первом коммерческом MIPS R3000 - 9 Мфлопс; на первом Intel Pentium - 15-40 Мфлопс.]. Для него требовались специальные сложные компиляторы и новая инфраструктура - и все лишь ради того, чтобы в конце концов получить производительность, в большинстве случаев уступающую производительности стремительно развивавшихся RISC-конкурентов! i860 мог быть очень быстрым процессором для вычислений с плавающей точкой - но между «мог» и «был» в большинстве приложений зияла огромная пропасть, которую было проще преодолеть, положившись на технический прогресс, благодаря которому даже безнадежно «тормознутая» в те годы архитектура x86 через несколько лет достигла такого же уровня производительности. Некоторое время Intel 80860 использовался в качестве специализированного программируемого DSP-процессора (графического ускорителя), но заметного распространения даже в такой ипостаси не получил.
Впрочем, полный провал i860 не помешал корпорациям Intel и Hewlett-Packard уже через два года инициировать разработку «суперпроцессора» Itanium, который должен был исправить ошибки 860-го процессора и стать заменой не только архитектуре x86, но и всем тогдашним RISC-архитектурам. Архитектура получила звучное название IA-64 (Intel Architecture for 64-bit), и поначалу казалось, что «пересадят» пользователей на Itanium едва ли не начиная с Pentium II. Itanium должен был с помощью специального полуаппаратного эмулятора поддерживать набор инструкций x86, так что переход с архитектуры IA-32 на IA-64 обещал быть безболезненным. «Крутизна» новинки была так очевидна, что Silicon Graphics, например, даже забросила разработку своей фирменной архитектуры MIPS, рассудив, что с Itanium ей все равно не сравниться.
Но если отбросить красивые слова и посмотреть, что получилось на практике, то следует признать, что проект Itanium «блестяще провалился». Вначале очень долго задерживался первый Itanium (Merced). Потом некстати вылезла со своими процессорами AMD и вынудила Intel ввязаться в «гонку мегагерц», по итогам которой «устаревшая» архитектура x86 сделала такой колоссальный рывок, что однозначного «суперпроцессора» из со скрипом появившегося на свет Itanium уже не получилось. Затем была проведена большая «работа над ошибками», в ходе которой производительность и «производственные» технические характеристики Itanium 2 значительно улучшились, так что «итаниумное» семейство с трудом, но все же завоевало лидерство в производительности (особенно при вычислениях с плавающей точкой, критичных для научных расчетов). Но принципиально это ситуацию не изменило. Перспективы для иного, кроме как High-End-применения, у Itanium сегодня печальные - фактически AMD убила его развитие своими 64-разрядными процессорами. Да, старшие модели 64-разрядных Opteron в среднем проигрывают старшим Itanium 2 по производительности; однако проигрыш этот невелик и компенсируется тем, что «Оптероны» гораздо дешевле и не требуют специальной адаптации уже имеющихся программ к IA-64. В итоге получилось так, что Intel, конечно, предпочла бы использовать свою архитектуру IA-64 вместо чужой архитектуры AMD64, однако выбирая между быстрой потерей большей части серверного рынка, занятого сегодня процессорами Xeon, и утратой надежды на то, что Xeon в обозримом будущем будет заменен на Itanium, Intel выбрала первый вариант. А после введения в «Зионах» технологии EM64T (копии AMD64) от развития собственных Itanium-систем отказалась большая часть поставщиков серверов, начиная с IBM и заканчивая Dell. Даже соразработчик Itanium компания Hewlett-Packard (как и SGI, которая ради IA-64 поставила крест на своей процессорной архитектуре PA-RISC) потихоньку сворачивает линейку продуктов на основе этих CPU. Так что злая ирония про «Itanic» (по аналогии с «Titanic») сегодня, к сожалению, уместна как никогда.
Кроме Intel попытку внедрить VLIW-архитектуру в повседневную жизнь предпринимала со своими x86-совместимыми процессорами небезызвестная Transmeta. У команды, в которой работал сам Линус Торвальдс, не было претензий на «новую сверхархитектуру», но процессоры они создали не менее интересные. Transmeta не стала проталкивать свой VLIW как индустриальный стандарт, а сосредоточилась на разработке специального софта, полностью имитирующего (программно!) на VLIW-процессоре обычную архитектуру x86. Производительностью такое решение не отличалось, но зато было простым (ибо VLIW архитектурно проще), дешевым (ибо простым) и потребляющим совсем немного энергии (в силу все той же простоты), что позволило Transmeta вполне успешно позиционировать свои CPU в нишу недорогих мобильных процессоров и даже процессоров для блейд-серверов. К сожалению, производственные трудности и появление технологии Centrino, которая свела конкуренцию на мобильном рынке почти к нулю, привели к тому, что Transmeta терпела огромные убытки. Так что судьба двух доступных пока VLIW-архитектур - Intel Itanium 2 и Transmeta Efficeon - очень похожа. Обе оказались вытеснены в узкоспециализированные ниши: Itanium 2 - в высокопроизводительную; Efficeon - в экономичную.
