Non. Une VM peut faire dynamiquement des optimisations de très haut niveau qui ne sont pas possible à implémenter statiquement.
Il y a aussi des optimisations liées à la machine cible : en C "standard", il faut choisir les optimisations (386, 686, etc.) et filer autant de versions, avec un compilateur JIT, celui-ci peut déterminer "à la volée" les optimisations éventuelles.
Contrairement à ce que raconte Timaniac, il est bien entendu parfaitement possible de faire du garbage collecting sans utiliser de VM, de même que de la reflection, etc
Eh oh j'ai jamais dis ca :) Il y a bien des GC pour C++ par exemple. Comme il y a des possibilité de reflection également en C++ avec certains outils. Mais c'est pas en standard dans le langage. Et pour la sécurité (les AppDomain par exemple), j'ai beaucoup plus de doute sur la faisabilité (mais bon ca doit pouvoir se faire). Un environnement d'exécution comme Java ou .NET/Mono propose ces services en standard, et potentiellement pour tous ceux qui ciblent le code intermédiaire de ces VM. La VM constitue plutôt l'ensemble d'instructions "imposées" qui permet de contrôler et d'obtenir un certain nombre de garanties à l'exécution du code natif résultant.
En fait, beaucoup de gens (comme Timaniac) confondent runtime et VM.
J'ai pourtant tenté d'expliqué que la VM n'était qu'une "vision" du programmeur, et qu'à l'exécution c'était kif kif bourriqot. D'ailleur je parles dès que possible d'"environnement d'exécution", plutôt que de VM.
Ceci dit, comme le montre l'exemple de GCJ, compiler nativement un langage comme Java ne pose pas de problèmes particuliers.
Euh ca fait quand même un moment qu'ils courraient après ;)
Et puis au final un bout de code compilé avec GCJ tourne généralement moins vite qu'un bout de code tournant sur la JVM de Sun donc bon l'intérêt... Cela dis ca reste utile pour faire du JIT sans aucune interprétation.
(désolé pour les sources, mais http://shootout.alioth.debian.org/debian/ ne tient plus compte de GCJ, me demande pas pourquoi)
[^] # Re: C# et le libre...
Posté par TImaniac (site web personnel) . En réponse à la dépêche talweg, une migration vers Mono. Évalué à 2.
Il y a aussi des optimisations liées à la machine cible : en C "standard", il faut choisir les optimisations (386, 686, etc.) et filer autant de versions, avec un compilateur JIT, celui-ci peut déterminer "à la volée" les optimisations éventuelles.
Contrairement à ce que raconte Timaniac, il est bien entendu parfaitement possible de faire du garbage collecting sans utiliser de VM, de même que de la reflection, etc
Eh oh j'ai jamais dis ca :) Il y a bien des GC pour C++ par exemple. Comme il y a des possibilité de reflection également en C++ avec certains outils. Mais c'est pas en standard dans le langage. Et pour la sécurité (les AppDomain par exemple), j'ai beaucoup plus de doute sur la faisabilité (mais bon ca doit pouvoir se faire). Un environnement d'exécution comme Java ou .NET/Mono propose ces services en standard, et potentiellement pour tous ceux qui ciblent le code intermédiaire de ces VM. La VM constitue plutôt l'ensemble d'instructions "imposées" qui permet de contrôler et d'obtenir un certain nombre de garanties à l'exécution du code natif résultant.
En fait, beaucoup de gens (comme Timaniac) confondent runtime et VM.
J'ai pourtant tenté d'expliqué que la VM n'était qu'une "vision" du programmeur, et qu'à l'exécution c'était kif kif bourriqot. D'ailleur je parles dès que possible d'"environnement d'exécution", plutôt que de VM.
Ceci dit, comme le montre l'exemple de GCJ, compiler nativement un langage comme Java ne pose pas de problèmes particuliers.
Euh ca fait quand même un moment qu'ils courraient après ;)
Et puis au final un bout de code compilé avec GCJ tourne généralement moins vite qu'un bout de code tournant sur la JVM de Sun donc bon l'intérêt... Cela dis ca reste utile pour faire du JIT sans aucune interprétation.
(désolé pour les sources, mais http://shootout.alioth.debian.org/debian/ ne tient plus compte de GCJ, me demande pas pourquoi)