Tem havido muita publicidade sobre os compiladores JIT para linguagens como Java, Ruby e Python. Como os compiladores JIT são diferentes dos compiladores C / C ++ e por que os compiladores escritos para Java, Ruby ou Python são chamados de compiladores JIT, enquanto os compiladores C / C ++ são chamados de compiladores?
Respostas:
Os compiladores JIT compilam o código rapidamente, imediatamente antes da execução ou mesmo quando já estão em execução. Dessa forma, a VM em que o código está sendo executado pode procurar padrões na execução do código para permitir otimizações que seriam possíveis apenas com informações em tempo de execução. Além disso, se a VM decidir que a versão compilada não é boa o suficiente por qualquer motivo (por exemplo, muitas falhas de cache ou código frequentemente lançando uma exceção específica), poderá decidir recompilar de uma maneira diferente, levando a uma experiência muito mais inteligente. compilação.
Por outro lado, os compiladores C e C ++ não são tradicionalmente JIT. Eles são compilados em um único tiro apenas uma vez na máquina do desenvolvedor e, em seguida, um executável é produzido.
JIT é a abreviação de compilador just-in-time, e o nome é misson: durante o tempo de execução, determina otimizações de código que valem a pena e as aplica. Ele não substitui os compiladores comuns, mas faz parte dos intérpretes. Observe que idiomas como Java, que usam código intermediário, têm ambos : um compilador normal para tradução de código intermediário e intermediário e um JIT incluído no interpretador para aumentar o desempenho.
As otimizações de código certamente podem ser executadas por compiladores "clássicos", mas observe a principal diferença: os compiladores JIT têm acesso aos dados em tempo de execução. Esta é uma enorme vantagem; explorá-lo corretamente pode ser difícil, obviamente.
Considere, por exemplo, 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;
}
Um compilador normal não pode fazer muito sobre isso. Um compilador JIT, no entanto, pode detectar que isso msó é chamado k==0por algum motivo (coisas assim podem acontecer à medida que o código muda com o tempo); ele pode criar uma versão menor do código (e compilá-lo no código nativo, embora eu considere isso um ponto secundário, conceitualmente):
m(a : String, b : String) {
return a.length + b.length - 7;
}
Nesse ponto, provavelmente alinhará a chamada do método, já que é trivial agora.
Aparentemente, o Sun descartou a maioria das otimizações javacusadas no Java 6; Disseram-me que essas otimizações dificultavam muito o JIT e o código compilado ingenuamente era mais rápido no final. Vai saber.
mcom uma versão que não verificar kuma vez que seria incapaz de provar que mpoderia nunca mais ser chamado com um diferente de zero k, mas mesmo sem ser capaz de provar que poderia substituir com 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 sempre , o que significa que não é uma função da entrada ou do ambiente, é seguro deixar o teste - mas determinar isso exige análise estática, que é muito cara e, portanto, acessível apenas em tempo de compilação. Um JIT pode vencer quando um caminho através de um bloco de código é usado com muito mais frequência do que outros, e uma versão do código especializada para esse caminho seria muito mais rápida. Mas o JIT ainda emitirá um teste para verificar se o caminho rápido se aplica e seguir o "caminho lento", se não.
Base* pparâmetro e chama funções virtuais por meio dele; A análise de tempo de execução mostra que o objeto real apontado para sempre (ou quase sempre) parece ser do Derived1tipo. O JIT poderia produzir uma nova versão da função com chamadas estaticamente resolvidas (ou mesmo embutidas) a Derived1métodos. Esse código seria precedido por uma condicional que verifica se po ponteiro da Derived1tabela está apontando para a tabela esperada ; caso contrário, ele salta para a versão original da função com suas chamadas de método resolvidas dinamicamente mais lentamente.