Автор сам придумал эту мощную шутку или так в оригинале было?

Новость не читал @ сразу отвечал
Politura, mag_ai, процессор не может быть одновременно VLIW и RISC?
RISC - сокращенный набор быстрых инструкций, VLIW - длинное командное слово. Не вижу никакого противоречия.

Как-то у Вас все смешалось.
Начнем с того, что да, джава-код работает поверх виртуальной машины. Виртуальную машину джавы перенесли уже на тонну архитектур, даже на отечественный Эльбрус. Поэтому все джава такая из себя ынтырпрайзная, что работает везде. Джава на мипсах уже давно есть.
Производительность VLIW действительно в большинстве случаев зависит от компилятора. Но тех оптимизаций, которые сейчас есть в том же gcc, думаю, достаточно.
Дальвик - другая виртуальная машина, которая написана иначе: с упором не на стек, а на регистры, тк у RISC процессоров их довольно много, в отличие от х86.
SIMD - это single instruction multiple data. Если мне не изменяет память, то это просто набор команд, разработанный для обработки мультимедиа данных. Подробнее на википедии найдете.
Честно говоря, я не сильно понимаю, зачем нужна эта головная боль с эмуляцией ARM'а на MIPS'ах, ибо толку - с гулькин нос. Работать действительно будет, но медленно. Выгоднее будет пересобрать весь софт нативно под мипс.
Ведроид уже сейчас прекрасно бегает на мипсах и на х86.

Добавлено спустя 2 минуты 54 секунды:

А Вы понимаете, из-за чего произошло или не произошло повышение производительности при переходе на 64 бита? Бьюсь об заклад, что нет.

Добавлено спустя 20 минут 39 секунд:

Давайте рассмотрим пример программы, которая складывает 2 64битных числа для архитектуры х86 в исполнении 32 и 64 бита.
Код

Собираем с помощью gcc: gcc -S test.c -m32 и gcc -S test.c -m64, соответственно, чтобы получить ассемблерный листинг.
Теперь смотрим на листинги:
32 бита

64 бита

Для удобства сравним количество строчек в листингах:

Naoru-kun зачем все сравнивать-то? Выделили бы только процедуру:
32

64

дальше не читал отвечаю сразу - не может.
а дальше еще хуже чем у меня каша.
я вам еще раз пишу - как можно решить задачу доступа к simd другим методом?
вот скажем человек использовал neon скомпилировал байт-код - дальше что? как он по вашей логике станет исполнятся на sse? (грубый пример)

ну кто будет пересобирать приложения в гугол плей кто? или вы думаете что разработчики туда "исходные коды" постят?
а потом еще нужен реестр телефонов - чтоб выдавать приложение под архитектуру нужную... о это телефон "хунь пинь" он на мипсах ему эту сборку а это "вань пинь" ему на армах. бред байт-код никто пересобирать в гугол плей не будет.
я еще раз пишу для не понимающих - стоит проблема ни системы а софта который на этой системе будет работать.
и да у интела костыль с далвике который помогает переварить код заточенный под армы и это транслятор грубо говоря neon >> sse других вариантов даж у интла не было.

глупости, в эру когда 99% когда пишется на языках высокого уровня, а языки эти имеют кросс-компилятор/интерпретатор - современным программистам ничего изучать не надо, компилятор все сделает за них... а тем кто использует asm, это уже программеры другого уровня, для них почитать ман по инструкциям нового проца тоже не составляет проблемы, я вот десятки раз на gcc писал код и для ARM и для MIPS, в т.ч. и патчи с asm-вставками для современных ТВ, роутеров, медиабоксов - никаких проблем

для серверного сегмента, мир клином не сошелся на смартах

да конечно не знает, откуда человеку такое знать если он судит об этом по бенчмаркам... если он понимает ограничениях 32ух битной адресации уже хорошо, что уж говорить об понимании того как выполняются на процессоре инструкции, как в примере с теми же 64ех разрядными int-ами

лолшто? 95% устройств на ARM (Samsung,Qualcomm,MediaTek)