>Впрочем жабистам и прочим придуркам которые даже не имеют представления в какой
>именно код трансформируется их конструкция - простительно.

Что это, мы-то, как раз-таки, имеем представление в какой код транслируется байткод: на [i386] получается код x86, на [amd64] -- x86-64, на [sparc] -- код для risc-процессора SPARC, на [mips], очевидно же(!) -- код MIPS, на [arm] -- код ядра процессоров ARM, если нету пришлёпки Jazelle DBX.

Притом что байткод переносим между архитектурами без перекомпиляции исходников, а конкретная виртуальная машина оптимизирует выполнение "по месту" с учётом особенностей CPU (длина конвеера, количество РОН, размер кэша, объём оперативной памяти). Количество аппаратных параметров, которые учитываются JVM для обеспечения такой же скорости исполнения как и у блобов, полученных методом красноглазой оптимизации исходников C++, не так много, но они важны для выбора правильной стратегии GC и тем самым влияют на общий отклик java-приложения. Некоторые java-приложения замахиваются даже на реал-тайм режим исполнения (Oracle/BEA JRockit JVM, IBM J9).

>Что с тупых и убогих
>взять?Они только на форумах бухтеть умеют, а "под микроскопом" тот бред
>выдаваемый компилером и JIT ни разу не видели все-равно.Там же высокие
>концепции!Взять кластеров на 4-ядерниках побольше - и вот вам мировой рекорд!Главное
>взять достаточно много машин :D

Кто там говорил, что микроядро всё время будет проигрывать монолитному ядру в эффективности? Торвальдс(tm), кажется. Так напишите Hadoop на C/C++, чтобы доказать обратное. :))