Et on en revient a la necessite d'avoir une grammaire du langage de programmation qui soit suffisamment expressive. Sinon, ces optimisations sont tres difficiles a mettre en oeuvre.
C'est bien pour cela que le JIT a attendu des langages comme Java ou C# pour devenir populaire.
On a surtout besoin de grammaires expressives.
Dans le langage auquel je pensais (toujours le même), Lisaac, la conditionnel, les briques de bases pour les boucles n'existent pas. Le compilateur ne connait que 7 primitives (-,*,/,and, or, =, >). Toute la lib est faîte avec ça.
Le if est une résolution dynamique sur les objets true et false héritant de booléan. Le compilateur l'optimise pour retomber sur un if comme en C. Ce qui fait que toutes les structures de ce type n'importe où dans le code sont optimisées. De même pour les récursives etc...
Plus ta grammaire est minimaliste, plus le compilateur se concentre sur la sémantique du code, pare que tu retombes toujours dessus quand tu fait l'analyse sémantique dans le compilateur (le micro langage interne).
Et c'est là que les optimisations sont possibles.
Le nombre de primitives dans Java et C# sont énormes, (http://isaacos.loria.fr/li_simplicity.html ), par contre le langage de la machine virtuelle est sufisament minimaliste et expressif pour que les optims soient faites dessus.
Cependant, l'analyse statique restera toujours limitee. Le comportement d'un programme depend de son code et de ses parametres en entree. Une optimisation statique a la compilation ne peut optimiser que le code d'un point de vue general. Elle ne peut pas connaitre quelle fonction est appelee plus souvent dans la pratique. C'est la que les optimisations JIT interviennent. Elles regardent le code s'executer et peuvent trouver les fonctions qui sont reellement utilisees en permanence.
Le C etant compile en assembleur avant d'etre execute, toute l'information sur la notion de fonction et de variable est perdue. Meme si cette information perdurait, a terme, la grammaire du C est trop peu expressive a mon sens pour permettre des optimisations de longue haleine (pas de notion d'interface, pas de notion de dictionnaire, utilisation de pointeurs pour gerer des tableaux, utilisation de pointeurs sans types, etc).
Donc plus ca va, plus le C va etre a la rue parce qu'il ne peut guere evoluer. D'un autre cote, cette stabilite est aussi ce qui a fait son succes.
Il y a C et C : il y a C écrit par un humain et C généré par un compilateur.
Le C écrit par un être humain exprime de la sémantique humaine : c'est à dire que le code est proche d'une représentation humaine du programme et moins un représentation adaptée à la machine.
Il est par exemple quasiment impensable qu'on s'amuse à faire un gros malloc au début et gérer les pointeurs pour faire en sorte que la mémoire cache soit utilisée au mieux. Ca devient vite ingérable. Par contre un compilateur peut le faire.
De même, souvent, tu vas utiliser des chaînes pour représenter une structure sémantique préfixée, alors que des nombres peuvent le faire, car c'est bijectif. C'est un peu ce qu'on fait dans les bases de données relationnelles.
Il est vrai qu'en l'état actuel des choses, on devrait réfléchir non à la machine virtuelle, mais à une espèce de programme possédant des informations sur son code et capable dans certains cas de générer son propre code. Mais il faut faire très attention : là où la machine virtuelle virtualise tout, il faudrait un système qui permette d'utiliser des optimisations faites par les VM seulement là et quand c'est utile.
C'est en tout cas une piste intéressante, mais le problème est qu'elle impose de connaître ton assembleur cible ou d'embarquer une part du compilateur (le back end de GCC par exemple)...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ...
Posté par Ontologia (site web personnel) . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 2.
C'est bien pour cela que le JIT a attendu des langages comme Java ou C# pour devenir populaire.
On a surtout besoin de grammaires expressives.
Dans le langage auquel je pensais (toujours le même), Lisaac, la conditionnel, les briques de bases pour les boucles n'existent pas. Le compilateur ne connait que 7 primitives (-,*,/,and, or, =, >). Toute la lib est faîte avec ça.
Le if est une résolution dynamique sur les objets true et false héritant de booléan. Le compilateur l'optimise pour retomber sur un if comme en C. Ce qui fait que toutes les structures de ce type n'importe où dans le code sont optimisées. De même pour les récursives etc...
Plus ta grammaire est minimaliste, plus le compilateur se concentre sur la sémantique du code, pare que tu retombes toujours dessus quand tu fait l'analyse sémantique dans le compilateur (le micro langage interne).
Et c'est là que les optimisations sont possibles.
Le nombre de primitives dans Java et C# sont énormes, (http://isaacos.loria.fr/li_simplicity.html ), par contre le langage de la machine virtuelle est sufisament minimaliste et expressif pour que les optims soient faites dessus.
Cependant, l'analyse statique restera toujours limitee. Le comportement d'un programme depend de son code et de ses parametres en entree. Une optimisation statique a la compilation ne peut optimiser que le code d'un point de vue general. Elle ne peut pas connaitre quelle fonction est appelee plus souvent dans la pratique. C'est la que les optimisations JIT interviennent. Elles regardent le code s'executer et peuvent trouver les fonctions qui sont reellement utilisees en permanence.
Le C etant compile en assembleur avant d'etre execute, toute l'information sur la notion de fonction et de variable est perdue. Meme si cette information perdurait, a terme, la grammaire du C est trop peu expressive a mon sens pour permettre des optimisations de longue haleine (pas de notion d'interface, pas de notion de dictionnaire, utilisation de pointeurs pour gerer des tableaux, utilisation de pointeurs sans types, etc).
Donc plus ca va, plus le C va etre a la rue parce qu'il ne peut guere evoluer. D'un autre cote, cette stabilite est aussi ce qui a fait son succes.
Il y a C et C : il y a C écrit par un humain et C généré par un compilateur.
Le C écrit par un être humain exprime de la sémantique humaine : c'est à dire que le code est proche d'une représentation humaine du programme et moins un représentation adaptée à la machine.
Il est par exemple quasiment impensable qu'on s'amuse à faire un gros malloc au début et gérer les pointeurs pour faire en sorte que la mémoire cache soit utilisée au mieux. Ca devient vite ingérable. Par contre un compilateur peut le faire.
De même, souvent, tu vas utiliser des chaînes pour représenter une structure sémantique préfixée, alors que des nombres peuvent le faire, car c'est bijectif. C'est un peu ce qu'on fait dans les bases de données relationnelles.
Il est vrai qu'en l'état actuel des choses, on devrait réfléchir non à la machine virtuelle, mais à une espèce de programme possédant des informations sur son code et capable dans certains cas de générer son propre code. Mais il faut faire très attention : là où la machine virtuelle virtualise tout, il faudrait un système qui permette d'utiliser des optimisations faites par les VM seulement là et quand c'est utile.
C'est en tout cas une piste intéressante, mais le problème est qu'elle impose de connaître ton assembleur cible ou d'embarquer une part du compilateur (le back end de GCC par exemple)...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker