Bondieu d'bondieu d'bondieu: comment un code interprété peut-il être plus rapide qu'un code compilé? Je veux bien admettre que les VM fassent des progrès, mais ce n'est pas une raison pour imaginer que les compilateurs vont se dégrader pendant ce temps là...
Voir réponse à Jar Jar Binks. Les premières VM Java ne faisaient qu'interpréter. Mais une VM peut aussi compiler en natif, et exécuter. Il ne faut pas oublier que c'est du bytecode qu'il faut compiler, ce n'est pas du langage de haut niveau. Ensuite, idem pour l'optimisation du code natif. Un exemple simple. Quand tu fais de la compilation classique, tu vas dire au compilo de mettre telles et telles fonctions en inline, parce que tu sais que c'est une bonne optimisation. Ce genre de choix tu le fais 1 fois pour toutes, et tu ne vas pas pouvoir le faire partout. Ce travail là, c'est aussi ce que peut faire une VM intelligente, en analysant le bytecode. Et plus elle est intelligente, plus elle va savoir quoi optimiser en inline et à quel moment (pour rester sur cet exemple). Bon, faut pas me demander plus de détails sur le "comment", sur l'intelligence de la VM. Et pour ce qui est de la prochaine JVM, je sais juste d'après des collègues qui ont essayé la beta que le gain de vitesse est vraiment remarquable, et que c'est du à l'application de ces principes. Donc, comme je l'ai dit dans l'autre post, etre plus rapide que du compilé ça doit etre possible avec cette nouvelle jvm, dans certains cas qui s'y pretent bien, mais ce n'est surement pas encore le cas général.
Par contre, si les recherches avancent dans cette direction, il est clair qu'il y a matière à avancer là où du coté compilation ça parait plus figé. (pas besoin que les compilateurs se dégradent).
[^] # Re: Oui, mais...
Posté par #3588 . En réponse à la dépêche Miguel DeIcaza et .NET. Évalué à 4.
Voir réponse à Jar Jar Binks. Les premières VM Java ne faisaient qu'interpréter. Mais une VM peut aussi compiler en natif, et exécuter. Il ne faut pas oublier que c'est du bytecode qu'il faut compiler, ce n'est pas du langage de haut niveau. Ensuite, idem pour l'optimisation du code natif. Un exemple simple. Quand tu fais de la compilation classique, tu vas dire au compilo de mettre telles et telles fonctions en inline, parce que tu sais que c'est une bonne optimisation. Ce genre de choix tu le fais 1 fois pour toutes, et tu ne vas pas pouvoir le faire partout. Ce travail là, c'est aussi ce que peut faire une VM intelligente, en analysant le bytecode. Et plus elle est intelligente, plus elle va savoir quoi optimiser en inline et à quel moment (pour rester sur cet exemple). Bon, faut pas me demander plus de détails sur le "comment", sur l'intelligence de la VM. Et pour ce qui est de la prochaine JVM, je sais juste d'après des collègues qui ont essayé la beta que le gain de vitesse est vraiment remarquable, et que c'est du à l'application de ces principes. Donc, comme je l'ai dit dans l'autre post, etre plus rapide que du compilé ça doit etre possible avec cette nouvelle jvm, dans certains cas qui s'y pretent bien, mais ce n'est surement pas encore le cas général.
Par contre, si les recherches avancent dans cette direction, il est clair qu'il y a matière à avancer là où du coté compilation ça parait plus figé. (pas besoin que les compilateurs se dégradent).