¿Cuáles son los inconvenientes de la compilación de JIT?

Question

La compilación Just In Time tiene varias ventajas teóricas: tiene más información sobre la máquina, el estado de los indicadores y cómo se usa el código. Le permite evitar la compilación que consume mucho tiempo antes de ejecutar, acelerando el ciclo de desarrollo.

De forma simplista, la compilación de JIT parece superior como enfoque; hay algunos gastos generales, pero si es lo suficientemente inteligente puede acelerar su código lo suficiente como para compensar eso.

Sin embargo, no creo que esa sea la historia completa. ¿Cuáles son los inconvenientes teóricos y prácticos? Sí, a menudo se menciona un "tiempo de arranque más lento", al igual que el "consumo de memoria aumentado", pero Me pregunto si hay más que eso.

Por ejemplo, ¿el rastreo y la compilación JIT basura la caché de la CPU? Si su programa es grande y realmente no tiene muchas rutas particularmente activas, ¿existe el riesgo de gastar más tiempo de rastreo y JIT-ting de lo que valdría la pena?

Parece probable que alguien haya escrito un artículo sobre esto o sobre la solución de problemas inherentes al JIT. Si alguien tiene medidas, mucho mejor.

Editar: Estoy hablando de la compilación Just In Time en comparación con la compilación anticipada (potencialmente con la optimización dirigida por la retroalimentación), no en comparación con la interpretación.

Answer 1

Si el JIT funciona correctamente, no hay una desventaja real. Habiendo dicho eso, a Sun le ha tomado mucho tiempo estabilizar el Hotspot porque es extremadamente complejo. Con respecto a los datos de referencia, siempre se puede ejecutar el siguiente experimento:

Run SPECjbb, SPECjvm, o en su propio punto de referencia y modificar la línea de comandos que se ejecuta java que incluyen:

-Xint 

Esto excluirá cualquier tiempo de ejecución compilación de ocurriendo.

Answer 2

El principal problema es que actualmente la máquina virtual debe cargarse; esto está cargando un compilador completo y el tiempo de ejecución en la memoria por lo que no será rápido.

Una vez cargado, la compilación y la creación de perfiles se pueden realizar en segundo plano a largo plazo y teóricamente pueden ser mucho más rápidos que cualquier lenguaje estáticamente compilado optimizando a mano para adaptarse a la situación de tiempo de ejecución. (Piense en el caso donde se determina que una función no tiene efectos secundarios y no se basa en datos externos que se llaman 50 veces por segundo con los mismos parámetros; un lenguaje compilado dinámicamente podría simplemente aprender a devolver una constante. Esto es algo un lenguaje compilado estáticamente simplemente no puede hacerlo genéricamente)

Tenga en cuenta que esto no siempre será un problema con las VM, si comienzan a construir las máquinas virtuales en el sistema operativo y reutilizan máquinas virtuales en varias aplicaciones, este problema iría lejos.

También vm bytecode tiende a hacer mucho más con muchos menos bytes. Esta es la razón por la cual Microsoft usó inicialmente máquinas virtuales en Excel/Word (pre-java), simplemente para reducir el tamaño del código.

Esta parte es solo una conjetura, pero creo que esto significaría que una CPU personalizada podría optimizarse para operar más rápidamente porque la lectura/escritura sería menos un cuello de botella.Los sistemas RISC tienden a suponer que las operaciones de CPU y no las E/S son el cuello de botella, no creo que esto sea siempre cierto: hacer más trabajo en un solo "código de operación" debería significar más oportunidades para que los fabricantes de CPU optimicen su hardware.

Mi punto? No hay desventajas innatas, y el principal inconveniente del mundo real es el tiempo de carga.

Oh, otro inconveniente en el mundo real, Java y C# tienden a asignar todos los objetos en el montón. Las asignaciones de Heap son mucho más rápidas en C#/Java que con C++, pero aún no están a la altura de las velocidades de asignación.

Answer 3

Por ejemplo, ¿el rastreo y la compilación JIT basura la caché de la CPU? Si su programa es grande y no tiene muchas rutas particularmente activas, ¿existe el riesgo de gastar más tiempo en el rastreo y el JIT-ting de lo que valdría la pena?

Eso es plausible. Pero todo el juego de optimización se trata de intercambiar varios factores para lograr el mejor resultado en el caso promedio. La mayoría de las aplicaciones tienen rutas relativamente frías y calientes, incluso si todas las rutas calientes están en las bibliotecas de clases estándar.

Además de lo que está diciendo es que efectivamente esta aplicación hipotética no vale la compilación JIT en absoluto. En ese caso, la "solución" sería ejecutarlo con la compilación JIT desactivada.

Parece probable que alguien haya escrito un artículo sobre esto o sobre la solución de problemas inherentes a JIT.

Habrías pensado así.

Pero la otra cara de la moneda es que las personas que crean y mantienen los compiladores JIT en las JVM de Oracle, IBM, etc. pueden verse limitadas de contarle al mundo sus ideas y resultados ... por razones comerciales. (Publicar el código fuente es una cosa, pero explicar por qué eligieron una estrategia en particular es otra cosa.) También está la cuestión de la motivación.