Premier point : Le minimalisme du code.
Ton argument, qu'un nombre minimalmiste de primitive est necessaire pour réaliser l'ensemble des optimisations, est (plutot) faux.
Si le langage donnait, directement dans ces primitives, la possibilité de définir une structure complexe (arborescente par ex.) avec des traitement dessu (un tri), le compilo aurrait la charge d'optimiser au mieux cette 'primitive' (qui ne semble pas minimale pourtant).
Bon ok, ajouter des primitives devient trés lourd a gérer au niveau compilo ...
Les gros avantages d'un minima de primitive sont a mon sens:
* La plus grande facilité d'implémenter un compilo "complet".
* La possibilité (future?) de prouver ces primitives de manière plus simple et plus complète; et ainsi par extension prouver des programees plus grand n'utilisant que ce jeux restreint d'instruction.
Second point : La suppression de la liaison dynamique
Les vft ont beaucoup été critiquée mais surtout a cause de leurs gestion catastrophique de l'héritage multiple (en héritage simple cette technique est trés efficace). En héritage multiple, il est necessaire d'introduire un décalage (offset) supplémentaire qui plombe les performances.
D'autres solutions ont biens étaient testé avant SmartEiffeil/Lissac:
* L'approche "SmallTalk" avec (pour faire simple) une recherche bourrin de la méthode récursivement dans les parents puis gestion d'un "cache de résolution" qui stocke qu'elle methode est appelé pour quel message: résultat le premier appel est plutot lent mais ensuite on accede directement à la bonne méthode.
* La méthode dite de "coloration": C'est plus compliqué à expliquer, mais en gros avec cette technique on peut réaliser une sorte de vft à simple indirection, mème en héritage multiple. De plus il serrait possible de repousser ce calcul au moment du link.
J'avait fait un test de cette technique en détournant le compilo SmartEiffel (seulement pour l'appel de procédures et sans paramètres, c'etait pour des tests ;-) ) et mes résultat sur mon archi d'alors (AMD K6-2 500) était plutot bon pour mon implémentation super-bourrine-et-rapide: temps comparable a l'implémentation "normale" de SmartEiffel. (ni plus lent, ni plus rapide).
Le gros problème de cette solution c'est qu'il n'y a jamais eu d'implémentation sur un compilo "complet" et "diffusé".
[Pour plus dinfos, voir les publications ici: http://www.lirmm.fr/~ducour/ C'est pas évident a comprendre, ce type fait parti des "aliens" de l'informatique.]
Troisième point : L'analyse de flot
Je suis trés critique vis-a-vis de ce point. Je suis complètement sûr qu'il est necessaire mais pas dans son implémentation actuelle.
Il manque, à mon sens, une "sauvegarde" optimisé des analyses précédentes. SmartEiffel à des performances pitoyables sur mon PC car il réanalyse la classe STRING a chaque compilation, ce n'est pas "gérable" comme tu le dit pour des programes plus "ample".
De plus cette technique est un frein a un chargement dynamique de code (librairies, plugin ...) et c'est inacceptable "de nos jours".
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par thecat . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 7.
Premier point : Le minimalisme du code.
Ton argument, qu'un nombre minimalmiste de primitive est necessaire pour réaliser l'ensemble des optimisations, est (plutot) faux.
Si le langage donnait, directement dans ces primitives, la possibilité de définir une structure complexe (arborescente par ex.) avec des traitement dessu (un tri), le compilo aurrait la charge d'optimiser au mieux cette 'primitive' (qui ne semble pas minimale pourtant).
Bon ok, ajouter des primitives devient trés lourd a gérer au niveau compilo ...
Les gros avantages d'un minima de primitive sont a mon sens:
* La plus grande facilité d'implémenter un compilo "complet".
* La possibilité (future?) de prouver ces primitives de manière plus simple et plus complète; et ainsi par extension prouver des programees plus grand n'utilisant que ce jeux restreint d'instruction.
Second point : La suppression de la liaison dynamique
Les vft ont beaucoup été critiquée mais surtout a cause de leurs gestion catastrophique de l'héritage multiple (en héritage simple cette technique est trés efficace). En héritage multiple, il est necessaire d'introduire un décalage (offset) supplémentaire qui plombe les performances.
D'autres solutions ont biens étaient testé avant SmartEiffeil/Lissac:
* L'approche "SmallTalk" avec (pour faire simple) une recherche bourrin de la méthode récursivement dans les parents puis gestion d'un "cache de résolution" qui stocke qu'elle methode est appelé pour quel message: résultat le premier appel est plutot lent mais ensuite on accede directement à la bonne méthode.
* La méthode dite de "coloration": C'est plus compliqué à expliquer, mais en gros avec cette technique on peut réaliser une sorte de vft à simple indirection, mème en héritage multiple. De plus il serrait possible de repousser ce calcul au moment du link.
J'avait fait un test de cette technique en détournant le compilo SmartEiffel (seulement pour l'appel de procédures et sans paramètres, c'etait pour des tests ;-) ) et mes résultat sur mon archi d'alors (AMD K6-2 500) était plutot bon pour mon implémentation super-bourrine-et-rapide: temps comparable a l'implémentation "normale" de SmartEiffel. (ni plus lent, ni plus rapide).
Le gros problème de cette solution c'est qu'il n'y a jamais eu d'implémentation sur un compilo "complet" et "diffusé".
[Pour plus dinfos, voir les publications ici: http://www.lirmm.fr/~ducour/ C'est pas évident a comprendre, ce type fait parti des "aliens" de l'informatique.]
Troisième point : L'analyse de flot
Je suis trés critique vis-a-vis de ce point. Je suis complètement sûr qu'il est necessaire mais pas dans son implémentation actuelle.
Il manque, à mon sens, une "sauvegarde" optimisé des analyses précédentes. SmartEiffel à des performances pitoyables sur mon PC car il réanalyse la classe STRING a chaque compilation, ce n'est pas "gérable" comme tu le dit pour des programes plus "ample".
De plus cette technique est un frein a un chargement dynamique de code (librairies, plugin ...) et c'est inacceptable "de nos jours".