Parece que todos los comentarios tratan sobre la publicidad, pero pocos sobre el rendimiento de la VM.
Por un lado, con un buen compijador JIT no tiene que haber problemas. El compilador JIT optimiza la ejecución para el hardware actual la primera vez que se lanza el ejecutable, por lo que para las siguientes ejeciones su rendimiento será muy bueno y optimizado para el hardware local.
Por otro lado la mayor parte de los chips ARM (¡incluidas varias versiones del iPhone!) usan las extensiones Jazelle [wikipedia.org]. ¿Y que son? Muchos las conocerán, pero para el que no lo sepa y no tenga ganas de leerse el enlace, son nada más y nada menos que la posibilidad de que el procesador ejecute bytecodes de java de forma nativa, por lo que la velocidad es tan rápida como la de cualquier otra instrucción en ensamblador.
En definitiva, por unas cosas o por otras no tiene por qué resentirse demasiado el rendimiento por usar una VM en vez de código nativo. Sólo se pueden notar grandes diferencias en el acceso a ciertas partes del hardware, como la aceleración 3D, pero para eso existen cosas como el NDK, que ejecuta código nativo.
por
pobrecito hablador
el Lunes, 30 Agosto de 2010, 12:29h
(#1235555)
Apoyo lo que dices pero no comparto la opinión de la gente que dice que la diferencia de rendimento se debe a compilación nativa o interpretación de bytecode
Se podría compilar (si oracle te da permiso) Java en código nativo.
La diferencia de rendimiento, generalmente está mucho más influenciada por otros factores que son parte del diseño del lenguaje
En ese sentido, Java seguirá siendo mucho más lento que lenguajes como C, C++, ADA y otros
Java tiene muchas decisiones en tiempo de ejecución donde otros lenguajes resuelven en tiempo de compilación (y eso no tiene nada que ver con el JIT)
Sobre el rendimiento de la VM Java
(Puntos:3, Informativo)( https://blog.rcorral.es/ | Última bitácora: Martes, 29 Junio de 2010, 11:58h )
Por un lado, con un buen compijador JIT no tiene que haber problemas. El compilador JIT optimiza la ejecución para el hardware actual la primera vez que se lanza el ejecutable, por lo que para las siguientes ejeciones su rendimiento será muy bueno y optimizado para el hardware local.
Por otro lado la mayor parte de los chips ARM (¡incluidas varias versiones del iPhone!) usan las extensiones Jazelle [wikipedia.org]. ¿Y que son? Muchos las conocerán, pero para el que no lo sepa y no tenga ganas de leerse el enlace, son nada más y nada menos que la posibilidad de que el procesador ejecute bytecodes de java de forma nativa, por lo que la velocidad es tan rápida como la de cualquier otra instrucción en ensamblador.
En definitiva, por unas cosas o por otras no tiene por qué resentirse demasiado el rendimiento por usar una VM en vez de código nativo. Sólo se pueden notar grandes diferencias en el acceso a ciertas partes del hardware, como la aceleración 3D, pero para eso existen cosas como el NDK, que ejecuta código nativo.
Disculpe que no me disculpe
Re:Sobre el rendimiento de la VM Java
(Puntos:0)Se podría compilar (si oracle te da permiso) Java en código nativo.
La diferencia de rendimiento, generalmente está mucho más influenciada por otros factores que son parte del diseño del lenguaje
En ese sentido, Java seguirá siendo mucho más lento que lenguajes como C, C++, ADA y otros
Java tiene muchas decisiones en tiempo de ejecución donde otros lenguajes resuelven en tiempo de compilación (y eso no tiene nada que ver con el JIT)