Enfin, plus généralement, plus il y a de couches présentes à l'exécution , plus le temps d'exécution tend à s'allonger, non ?
Il tend à s'allonger si on ne fait rien oui. Mais par contre plus on a de couches disponibles plus on va pouvoir faire d'optimisations post-compilation.
En C on ne peut pas faire d'optimisation à posteriori, une fois que le porgramme est lancé, sa partie executable (ie par la partie données) ne bouge pas sauf cas super particuliers et très casse gueule tel que l'assembleur automodifiant ou le self linking dynamique.
A l'inverse les programmes tournant sur une machine virtuelle peuvent s'optimiser tout seul en permanence. Par exemple lorsqu'il passent dans une fonction ils peuvent créer une table de hashage des paramêtres passés et de leur résultats et ainsi répondre instantanément si la fonction est appelé deux fois avec les mêmes paramêtres. De même ils peuvent faire sauter un paquet de tests et donc linéariser le code. Pareillement la machine virtuelle peut conserver une empreinte de la config système et ainsi court-circuiter un paquet d'appels systèmes en n'executant pas le bytecode et en plaçant la réponse directement au bon endroit etc.
En d'autres termes on passe d'un mode de calcul de branchement, éventuellement de prédiction de branchement à un mode de branchement direct.
A l'heure actuelle ces optimisations post-execution ne sont pas encore très rentables par rapport à la complexité qu'elles induisent dans la machine virtuelle, mais elles le deviennent. Sur des protocoles de communications complexes il est certain que les machines virtuelles finiront par battre à plate couture les programmes compilés traditionnels gràce a des meccanisme de prise d'empreinte mémoire et système qui leur permettront d'éviter la grosse majorité des tests.
[^] # Re: ...
Posté par Jerome Herman . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 4.
Il tend à s'allonger si on ne fait rien oui. Mais par contre plus on a de couches disponibles plus on va pouvoir faire d'optimisations post-compilation.
En C on ne peut pas faire d'optimisation à posteriori, une fois que le porgramme est lancé, sa partie executable (ie par la partie données) ne bouge pas sauf cas super particuliers et très casse gueule tel que l'assembleur automodifiant ou le self linking dynamique.
A l'inverse les programmes tournant sur une machine virtuelle peuvent s'optimiser tout seul en permanence. Par exemple lorsqu'il passent dans une fonction ils peuvent créer une table de hashage des paramêtres passés et de leur résultats et ainsi répondre instantanément si la fonction est appelé deux fois avec les mêmes paramêtres. De même ils peuvent faire sauter un paquet de tests et donc linéariser le code. Pareillement la machine virtuelle peut conserver une empreinte de la config système et ainsi court-circuiter un paquet d'appels systèmes en n'executant pas le bytecode et en plaçant la réponse directement au bon endroit etc.
En d'autres termes on passe d'un mode de calcul de branchement, éventuellement de prédiction de branchement à un mode de branchement direct.
A l'heure actuelle ces optimisations post-execution ne sont pas encore très rentables par rapport à la complexité qu'elles induisent dans la machine virtuelle, mais elles le deviennent. Sur des protocoles de communications complexes il est certain que les machines virtuelles finiront par battre à plate couture les programmes compilés traditionnels gràce a des meccanisme de prise d'empreinte mémoire et système qui leur permettront d'éviter la grosse majorité des tests.