2010-12-05 31 views
7

Java es un lenguaje OO muy bien diseñado, pero lo primero que noté es lo lento que es (en comparación con C++). Esto es probablemente porque tiene que atravesar otra capa de traducción (la VM) en lugar de ejecutarse directamente en el microcódigo nativo de la CPU.¿Hay una CPU que ejecute Java en microcódigo?

Mi pregunta: ¿Conoces algún intento de crear CPU específicas de Java que ejecuten Java de forma nativa sin requerir la VM implementada por software?

+5

Personas (con razón) quejándose de "Java es lento" quejándose en N ... (N-1) ...(Además, una CPU de propósito especial que ejecute bytecode de Java muy probablemente termine mucho más lento que una CPU de escritorio moderna que ejecuta una JVM normal). – delnan

+0

Bueno, el ensamblaje es aún más rápido, pero el tiempo que gana en rendimiento se convierte en tiempo de desarrollo (y multiplicado por 100 factores, tal vez ...) – digEmAll

+0

@skaffman Por lento quise decir más lento que un programa comparable en C++. Intenta ejecutar Eclipse (que AFAIK fue escrito en Java) dentro de una VMWare VM y ve a qué me refiero. –

Respuesta

17

Sun diseñó el procesador picoJava hace unos 10 años, pero nunca llegó a ninguna parte; no había mercado para él en ese momento, y las máquinas virtuales modernas hacen que el concepto no tenga sentido.

Luego está la incipiente arquitectura ARM Jazelle.

+1

+1 para obtener esta información precisa. Lo leeré en breve y trataré de entender por qué nunca fue a ningún lado. –

+1

@Android: nunca fue a ninguna parte porque no había mercado para eso, y porque las JVM del día * eran * lentas. No irá a ninguna parte hoy, porque las JVM modernas son * no * lentas. – skaffman

+1

@saffman el artículo de Wikipedia que acaba de presentar dice "acelerando la ejecución de bytecode hasta 20 veces, en comparación con la CPU Intel estándar con una JVM". - Esto es lo que quiero decir con "lento". Hoy damos por hecho que la CPU es más rápida, pero esto no es muy eficiente en cuanto a la energía ... Por lento, me refiero al lento ** er **. –

5

La única referencia que encontré hasta ahora a este dilema es el siguiente artículo:

http://www.theserverside.com/discussions/thread.tss?thread_id=59958

Mientras estaba inicialmente interesado en saber primero si hay Java-CPU y lo que son, cobertizos de este hilo algo de luz en por qué No he oído hablar de ninguno (hasta que lea las respuestas aprendidas aquí). El último comentario, por Alex Besogonov, parece ser la mejor explicación:

código de bytes de Java no es apto para ser ejecutado en el hardware real. Está basado en la pila, por lo que la canalización sale por la ventana. En la teoría , se puede hacer sobre la marcha traducción de la máquina basada en la pila a basada en registro, pero va a requerir MUCHOS transistores.

Entonces, en realidad, SIEMPRE es más efectivo para JIT-compilar el bytecode de Java y luego ejecutarlo en una CPU común. Hay es una excepción JVM para dispositivos de baja potencia donde la velocidad del hardware JVM no es un problema (recuerde Forth CPUs).

Por supuesto, el hardware todavía puede proporcionar algunas características para acelerar las JVM. Como punteros de reenvío asistidos por hardware que permiten crear en tiempo real en tiempo real compactación sin pausa GC (supongo que el hardware Azul tiene esta compatibilidad).

Esto es muy interesante. Gracias a todos por sus respuestas o comentarios.

5

Azul Systems diseña sistemas desde cero con (servicios masivos en ejecución) teniendo en cuenta Java, incluida la recolección de basura asistida por hardware.

También hay GCJ para compilar Java a código nativo, aunque no es una implementación completa de Java.

+7

Pero el * punto * total de la CPU Vega-3 de Azul es que * no * implementa el bytecode JVML. Es simplemente una CPU ortogonal bien diseñada. La inteligencia está en el compilador JVML a nativo (que en realidad es solo una variante con licencia del compilador C2 de Sun/Oracle que forma parte de la JVM de HotSpot) y no en la CPU. Las personas que fundaron Azul * vinieron * de los proyectos de CPU Java de Sun, y lo hicieron de esta manera precisamente porque se dieron cuenta de que la implementación de JVML en la CPU es * no * más rápida, es * más lenta *, porque descarta la optimización dinámica masiva potencial. –

+2

+1 para obtener esta información. Espero que este hilo se convierta en una referencia para los intentos existentes. –

+2

@ Jörg: sí, esta no es una muy buena respuesta a la pregunta. pero dado que suena como una pregunta bastante exploratoria (¿alguien ha hecho X? en lugar de ¿por qué Y no funciona?) que se apaga en una tangente parece apropiado. –

0

Es posible que desee probar JOP

Es de código abierto y se puede probar en su propio hardware.

Cuestiones relacionadas