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

FR>Не будет не из-за этого, а из-за того что место давно занято.

Ага, а когда оно было свободным — помешал всемирный еврейский заговор.

FR>Угу то-то эта ява так страшно тормозит.

"Страшно" тормозящую яву я видел только одну — неоптимизированный C-шный main loop по байткоду, который поставляется фирмой Sun, для а) отладки, и б) пусть каждый оптимизирует под свой процессор как хочет.
Именно эту работу я делал для Samsung-овский телефонов и digital TV — переписывал main loop на асме, что за неделю работы дало ускорение в 2 раза. Ещё в два раза дало ускорение оптимизация вызова методов и выкидывание некоторых "дублирующих" инструкций (вроде op_null и op_const0) и использование освободившегося места для комбинированных инструкций.

FR>"Интерпретор" у форта как ты наверно знаешь, имеет некторые особенности которые позволяют ему по скорости мало уступать тупым плохо оптимизирующим компиляторам (а явовские в мобилках именно такие), правда эти же особенности мешают построить хороший оптимизирующий компилятор. Но компиляторы у форта есть и посоревноватся с той же явой вполне могут.

Этого не может быть, потому, что этого не может быть никогда.
Любой, самый тупой из тупых компиляторов разворачивает байткод в последовательность комманд процессора, экономя на каждой комманде чтение опкода и джамп на хэндлер. У ARM эти две операции совмещены, но джамп занимает больше такта. У MIPS их надо делать отдельно, но он выполняет ещё одну инструкцию, в течении джампа. Итого — минимальная прибыль от компилятора, даже если он тупо работает со стеком и не занимается регистрами — 2-3 такта на инстукцию. Если он ещё регистры использует (даже без оптимизации) — то это ещё раза в 2 ускорение.

Фсё, я тему быстродействия больше в этом топике не обсуждаю. Если есть что-то конкретное в виде бенчмарков — можно обсудить в новом топике.