Ensuite ca serait bien d'arrêter de parler d'une "bonne grosse" machine virtuelle de la "lourdeur" d'une machine virtuelle, on parle d'un truc "virtuel", ca serait bien de le rappeler, concrêtement elle n'existe pas, c'est un concept purement intellectuel pour le développeur, c'est une couche d'abstraction lors de la phase de développement. D'ailleur on peut dire que GCC a une machine virtuelle qui est représenté par l'ensemble des instructions disponibles dans son langage intermédiaire "indépendant" du processeur.
TImaniac, c'est pas la première fois que je te surprend à dire une connerie, et en proférant souvent moi aussi, je décèle chez toi une certaine incompréhension sur la compilation et sa théorie.
Il y a machine virtuelle et machine virtuelle. Dans le cas qui nous préoccupe ici, Java et Mono, il s'agit d'une "vraie" machine virtuelle. C'est à dire que nous avons un programme, qui lit un espèce d'assembleur (à pile... j'en entend certain rigoler) et dispose de quelques primitives.
Voir pout Java : http://java.sun.com/docs/books/vmspec/html/Overview.doc.html
Donc, même si le pseudo compilateur java produit un pseudo assembleur, il faut le traduire cet assembleur, surtout qu'il est d'assez haut niveau. Ca prend du temps, tout ça
Un programme compilé n'a pas ce problème, l'assembleur est là, prêt à être exécuté.
Alors certes, dans une machine virtuelle, tu peux gagner du temps en faisant des tables de hashage sur des appels de fonctions très utilisées, tu peux réutiliser du code déjà "compilé". Mais toute la phase de compilation à la volée du pseudo-code (code objet) est à faire. Le compilateur est en quelques sorte dans ton programme, d'autant plus lourd que la machine virtuelle est haut niveau. La Java Virtual Machine, est assez haut niveau j'en veux pour preuve l'exemple
void createBuffer() {
int buffer[];
int bufsz = 100;
int value = 12;
buffer = new int[bufsz];
buffer[10] = value;
value = buffer[11];
}
might be compiled to
Method void createBuffer()
0
bipush 100
// Push bufsz
2
istore_2
// Store bufsz in local 2
3
bipush 12
// Push value
5
istore_3
// Store value in local 3
6
iload_2
// Push bufsz...
7
newarray int
// ...and create new array of int
9
astore_1
// Store new array in buffer
10
aload_1
// Push buffer
11
bipush 10
// Push constant 10
13
iload_3
// Push value
14
iastore
// Store value at buffer[10]
15
aload_1
// Push buffer
16
bipush 11
// Push constant 11
18
iaload
// Push value at buffer[11]
19
istore_3
// ...and store it in value
20
return
J'ose pas imaginer ça en asm x86, avec toute la gestion de la mémoire derrière... (et la super instruction "newarray int").
Conclusion, la bataille entre compilateur et machine virtuelle fait rage depuis 20 ans, voire plus, avec les mêmes arguments.
Je pense que le futur est à une synthèse entre les deux, ou plutôt à une intégration de concepts issu de l'interprétation dans la compilation : On peut imaginer un langage dans lequel on spécifie les intervales de définition les plus probables, où l'analse de flot détecterait des fonctions souvent rappelées et peu susceptibles de donner des résultats changeant en squeezant les appels et les remplaçant par des tables de hash. OU encore, mais ça me plait moins, d'entraîner le code sur des données et de recompiler sur des statistiques (Intel le fait).
Bref une belle thèse de doctorat (s'il y a des étudiants en Master 2 ou 1 prometeur dans la salle, contactez moi, je ferai passer) en perspective.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le passage Mono dans le document
Posté par Ontologia (site web personnel) . En réponse au journal Mono et Gnome. Évalué à 2.
TImaniac, c'est pas la première fois que je te surprend à dire une connerie, et en proférant souvent moi aussi, je décèle chez toi une certaine incompréhension sur la compilation et sa théorie.
Il y a machine virtuelle et machine virtuelle. Dans le cas qui nous préoccupe ici, Java et Mono, il s'agit d'une "vraie" machine virtuelle. C'est à dire que nous avons un programme, qui lit un espèce d'assembleur (à pile... j'en entend certain rigoler) et dispose de quelques primitives.
Voir pout Java : http://java.sun.com/docs/books/vmspec/html/Overview.doc.html
Donc, même si le pseudo compilateur java produit un pseudo assembleur, il faut le traduire cet assembleur, surtout qu'il est d'assez haut niveau. Ca prend du temps, tout ça
Un programme compilé n'a pas ce problème, l'assembleur est là, prêt à être exécuté.
Alors certes, dans une machine virtuelle, tu peux gagner du temps en faisant des tables de hashage sur des appels de fonctions très utilisées, tu peux réutiliser du code déjà "compilé". Mais toute la phase de compilation à la volée du pseudo-code (code objet) est à faire. Le compilateur est en quelques sorte dans ton programme, d'autant plus lourd que la machine virtuelle est haut niveau. La Java Virtual Machine, est assez haut niveau j'en veux pour preuve l'exemple
void createBuffer() {
int buffer[];
int bufsz = 100;
int value = 12;
buffer = new int[bufsz];
buffer[10] = value;
value = buffer[11];
}
might be compiled to
Method void createBuffer()
0
bipush 100
// Push bufsz
2
istore_2
// Store bufsz in local 2
3
bipush 12
// Push value
5
istore_3
// Store value in local 3
6
iload_2
// Push bufsz...
7
newarray int
// ...and create new array of int
9
astore_1
// Store new array in buffer
10
aload_1
// Push buffer
11
bipush 10
// Push constant 10
13
iload_3
// Push value
14
iastore
// Store value at buffer[10]
15
aload_1
// Push buffer
16
bipush 11
// Push constant 11
18
iaload
// Push value at buffer[11]
19
istore_3
// ...and store it in value
20
return
trouvé ici http://java.sun.com/docs/books/vmspec/html/Compiling.doc.htm(...)
J'ose pas imaginer ça en asm x86, avec toute la gestion de la mémoire derrière... (et la super instruction "newarray int").
Conclusion, la bataille entre compilateur et machine virtuelle fait rage depuis 20 ans, voire plus, avec les mêmes arguments.
Je pense que le futur est à une synthèse entre les deux, ou plutôt à une intégration de concepts issu de l'interprétation dans la compilation : On peut imaginer un langage dans lequel on spécifie les intervales de définition les plus probables, où l'analse de flot détecterait des fonctions souvent rappelées et peu susceptibles de donner des résultats changeant en squeezant les appels et les remplaçant par des tables de hash. OU encore, mais ça me plait moins, d'entraîner le code sur des données et de recompiler sur des statistiques (Intel le fait).
Bref une belle thèse de doctorat (s'il y a des étudiants en Master 2 ou 1 prometeur dans la salle, contactez moi, je ferai passer) en perspective.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker