Здравствуйте, WolfHound, Вы писали:

N>>Не из-за этого, а из-за своей изначальной инвалидности.
WH>А инвалидность заключалась в том, что он исполнял х86ой код в 10 раз медленнее конкурентов.
WH>Все остальные проблемы интел бы решил в течении пары лет.

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

То, что при этом Intel ещё и был настолько самонадеян, что вместо нормального x86 засунул туда слабый эмулятор — заслуга облаковитателей, поддержанная маркетолухами. Сколько их тогда было — видно по историям с Rambus и NetBurst. Ну да, время такое — если бы пузырь доткомов не схлопнулся, они могли бы и проскочить ещё лет пять. Но не больше.

Фактически, они нащупали работающий подход к этим вопросам только в SandyBridge.

N>>Но остаётся вопрос принципиально разных архитектур (CPU vs. GPU) и оптимизаций под конкретное железо. А вот тут большая загвоздка — те, кто для конкуренции вылизывает даже 1%, не пойдут на тотальный AOT, потому что в нём всегда будет меньше гибкости. А таких достаточно много.
WH>1)И все они сливают вот этой штуке http://halide-lang.org/

Посмотрю, но не сегодня.

WH>2)Если очень хочется, то код можно заточить под конкретный процессор.

Можно.

WH>Создаём библиотеку примитивов процессора. И учим ВМ для этого процессора транслировать эти примитивы в соответствующие машинные коды.

А вот именно примитивы процессора могут быть перебором. Скорее тут надо точить под общий подход и конкретные количественные особенности, типа "любой векторный кратный 128 битам".