Non on est en open source donc tu as les sources donc tu peux recompiler pour ta plateforme avec toutes les optims de la mort qui tue.
Tu peux mais 90% des gens s'en balances et font urpmi/yum/apt-get install machintruc et c'est un binaire générique qui arrive sur leur machine.
Le temps qu'il passe à faire l'optim à la volée ne bouffe-t'il le temps gagné sur l'éxecution de l'optim?
Evidemment que cela peut prendre du temps, en général d'ailleur on le sent à la première exécution, il y a justement cette première étape de "pré-compilation" en code natif. Enfin si l'algo en question est souvent réutiliser après je te laisse deviner les gains de perfs.
Si les langages qui font appellent à JIT sont plus lent, ce n'est pas à cause de cela, c'est plutôt pour d'autres raisons : gestion mémoire, vérification des références, etc.
Enfin dans tous les cas c'était juste histoire de montrer que le langage ne fait pas tout, il faut aussi tenir compte du boulot du compilo.
[^] # Re: Ça dépend !
Posté par TImaniac (site web personnel) . En réponse au message que choisir C où C++. Évalué à 2.
Tu peux mais 90% des gens s'en balances et font urpmi/yum/apt-get install machintruc et c'est un binaire générique qui arrive sur leur machine.
Le temps qu'il passe à faire l'optim à la volée ne bouffe-t'il le temps gagné sur l'éxecution de l'optim?
Evidemment que cela peut prendre du temps, en général d'ailleur on le sent à la première exécution, il y a justement cette première étape de "pré-compilation" en code natif. Enfin si l'algo en question est souvent réutiliser après je te laisse deviner les gains de perfs.
Si les langages qui font appellent à JIT sont plus lent, ce n'est pas à cause de cela, c'est plutôt pour d'autres raisons : gestion mémoire, vérification des références, etc.
Enfin dans tous les cas c'était juste histoire de montrer que le langage ne fait pas tout, il faut aussi tenir compte du boulot du compilo.