Sinon, ces optimisations post-génération de code exécutables sont quand même applicables aux machines physiques ?
Soit tu met des primitives dans le processeur et j'ose pas imaginer les conséquences...
Soit tu te débrouilles pour que le compilateur intègre les techniques que Kha citait plus haut. Et là ça devient assez chaud. Ca n'est possible à mon avis qu'avec :
- Un compilateur utilisant massivement une analyse de flot
- Un compilateur qui dispose de bonnes informations, à priori sur les statistiques d'utilisation du code (ie. distribution des valeurs les plus courantes en entrée des fonctions).
De là, soit tu t'amuses à compiler ton programme, à lui balancer une batterie de tests - en espérant qu'ils soient représentatifs - et à recompiler celui-ci en connaissance de cause, ou soit tu lui colle une sémantique du type contrat, définition d'intervals/ensemble afin d'avoir de bonnes infos sur le comportement de ton code.
Dans tous les cas c'est problématique, et faut bien analyser
- Quels appels extérieurs cela implique pour optimiser leur appel (table de hashage, etc...) et le cas échant, il faut que l'OS soit optimisé pour ça
- Les problèmes de mise à jour des données (table de hashage sur appels de fonction).
Dans le compilateur, il faudrait que l'analyse de flot analyse les sous graphes potentiellement très consommateurs en calculant leur complexité ainsi que les possibilités de "distributions" des paramètres dans l'intervalle possible (typiquement , on peut déduire, dans certains cas, par un moteur logique, que le param appliqué à la fonction f, dans le contexte se trouvera dans l'interval [20;100]).
Avec ça, le compilateur peut poser un système de table de hashage dessus, voire découper le code de la méthode en petit bout et la spécialiser aux seuls paramètres qui change.
Merci pour l'idée Kha, ça serait sympa à intégrer au compilo...
« 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é à 4.
Soit tu met des primitives dans le processeur et j'ose pas imaginer les conséquences...
Soit tu te débrouilles pour que le compilateur intègre les techniques que Kha citait plus haut. Et là ça devient assez chaud. Ca n'est possible à mon avis qu'avec :
- Un compilateur utilisant massivement une analyse de flot
- Un compilateur qui dispose de bonnes informations, à priori sur les statistiques d'utilisation du code (ie. distribution des valeurs les plus courantes en entrée des fonctions).
De là, soit tu t'amuses à compiler ton programme, à lui balancer une batterie de tests - en espérant qu'ils soient représentatifs - et à recompiler celui-ci en connaissance de cause, ou soit tu lui colle une sémantique du type contrat, définition d'intervals/ensemble afin d'avoir de bonnes infos sur le comportement de ton code.
Dans tous les cas c'est problématique, et faut bien analyser
- Quels appels extérieurs cela implique pour optimiser leur appel (table de hashage, etc...) et le cas échant, il faut que l'OS soit optimisé pour ça
- Les problèmes de mise à jour des données (table de hashage sur appels de fonction).
Dans le compilateur, il faudrait que l'analyse de flot analyse les sous graphes potentiellement très consommateurs en calculant leur complexité ainsi que les possibilités de "distributions" des paramètres dans l'intervalle possible (typiquement , on peut déduire, dans certains cas, par un moteur logique, que le param appliqué à la fonction f, dans le contexte se trouvera dans l'interval [20;100]).
Avec ça, le compilateur peut poser un système de table de hashage dessus, voire découper le code de la méthode en petit bout et la spécialiser aux seuls paramètres qui change.
Merci pour l'idée Kha, ça serait sympa à intégrer au compilo...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker