Ha habido mucha publicidad sobre los compiladores JIT para lenguajes como Java, Ruby y Python. ¿En qué se diferencian los compiladores JIT de los compiladores C / C ++, y por qué los compiladores escritos para Java, Ruby o Python se denominan compiladores JIT, mientras que los compiladores C / C ++ se llaman compiladores?
Respuestas:
Los compiladores JIT compilan el código sobre la marcha, justo antes de su ejecución o incluso cuando ya se están ejecutando. De esta manera, la VM donde se ejecuta el código puede verificar patrones en la ejecución del código para permitir optimizaciones que solo serían posibles con información de tiempo de ejecución. Además, si la máquina virtual decide que la versión compilada no es lo suficientemente buena por cualquier razón (por ejemplo, demasiadas fallas en la memoria caché o código que frecuentemente arroja una excepción particular), puede decidir recompilarla de una manera diferente, lo que lleva a una versión mucho más inteligente Compilacion.
Por otro lado, los compiladores C y C ++ tradicionalmente no son JIT. Se compilan en un solo disparo una sola vez en la máquina del desarrollador y luego se produce un ejecutable.
JIT es la abreviatura de compilador justo a tiempo, y el nombre es misson: durante el tiempo de ejecución, determina optimizaciones de código que valen la pena y las aplica. No reemplaza a los compiladores habituales, pero son parte de los intérpretes. Tenga en cuenta que los lenguajes como Java que usan código intermedio tienen ambos : un compilador normal para la traducción de código fuente a intermedio, y un JIT incluido en el intérprete para aumentar el rendimiento.
Ciertamente, los compiladores "clásicos" pueden realizar optimizaciones de código, pero tenga en cuenta la diferencia principal: los compiladores JIT tienen acceso a los datos en tiempo de ejecución. Esta es una gran ventaja; explotarlo adecuadamente puede ser difícil, obviamente.
Considere, por ejemplo, un código como este:
m(a : String, b : String, k : Int) {
val c : Int;
switch (k) {
case 0 : { c = 7; break; }
...
case 17 : { c = complicatedMethod(k, a+b); break; }
}
return a.length + b.length - c + 2*k;
}
Un compilador normal no puede hacer mucho al respecto. Sin embargo, un compilador JIT puede detectar que msolo se llama k==0por alguna razón (cosas como esa pueden suceder a medida que el código cambia con el tiempo); luego puede crear una versión más pequeña del código (y compilarlo en código nativo, aunque considero que esto es un punto menor, conceptualmente):
m(a : String, b : String) {
return a.length + b.length - 7;
}
En este punto, probablemente incluso alineará la llamada al método, ya que es trivial ahora.
Aparentemente, el Sol descartó la mayoría de las optimizaciones que javacsolía hacer en Java 6; Me han dicho que esas optimizaciones dificultaron que JIT hiciera mucho, y al final el código compilado ingenuamente fue más rápido. Imagínate.
mcon una versión que no comprobó kya que sería incapaz de demostrar que msería nunca se puede llamar con un no-cero k, pero incluso sin ser capaz de demostrar que podía reemplazar con static miss_count; if (k==0) return a.length+b.length-7; else if (miss_count++ < 16) { ... unoptimized code for m ...} else { ... consider other optimizations...}.
k=0 siempre , lo que significa que no es una función de la entrada o el entorno, es seguro abandonar la prueba, pero determinar esto requiere un análisis estático, que es muy costoso y, por lo tanto, solo asequible en el momento de la compilación. Un JIT puede ganar cuando una ruta a través de un bloque de código se toma con mucha más frecuencia que otras, y una versión del código especializada para esta ruta sería mucho más rápida. Pero el JIT aún emitirá una prueba para verificar si se aplica la ruta rápida , y tomar la "ruta lenta" si no.
Base* pparámetro y llama a funciones virtuales a través de él; El análisis de tiempo de ejecución muestra que el objeto real señalado siempre (o casi siempre) parece ser de Derived1tipo. El JIT podría producir una nueva versión de la función con llamadas a los Derived1métodos resueltas estáticamente (o incluso en línea) . Este código iría precedido por un condicional que verifica si pel puntero vtable apunta a la Derived1tabla esperada ; de lo contrario, salta a la versión original de la función con sus llamadas a métodos más lentas resueltas dinámicamente.