Les performances de Smart Eiffel sont dus à la suppression de la liaison dynamique.
Dans tous les langages objets, l'accès à une méthode spécialisé sur plusieurs classes dans l'arbre d'héritage se fait par une liaison dynamique, plus exactement une VFT (Virtual Function Table).
En gros, on a une structure avec un pointeur sur fonction que l'on peut parfois mettre dans un tableau.
En assembleur ça donne des trucs du genre "call dword ptr [_adresse_de_la_fonction]", ce qui implique :
- Que l'inlining est très limité
- Que le processeur est obligé de vider son cache mais aussi de laisser tomber toutes ses prédictions de branchements.
Donc une chute des performances.
A ma connaissance, tous les langages objets sauf (Smart) Eiffel et Lisaac fonctionnent comme ça.
Avec l'algorithme du produit cartésien de Ole Agesen et Craig Chambers (à peu près innaplicable), l'algorithme de Dominique Colnet est le premier à réussir à supprimer la liaison dynamique.
Un algorithme de prédiction de type détermine les types possibles pour le receveur et les paramètres, ce qui donne lieu à un switch afin de traiter chaque cas.
En plus, on peut enfin faire de l'inlining et de la spécialisation de code.
Le problème de Smart Eiffel, c'est qu'il traite tous les cas de résolution de type, même ceux, qui, dans le code tel qu'on le possède ne pourront jamais survenir.
Lisaac est le premier compilateur à analyser tout son code et de déterminer les types possibles et de ne traiter qu'eux seuls.
Ca permet d'éviter plus de 84 % de switch.
L'inlining est encore facilité, ainsi que la spécialisation de code.
Résultat, un décodeur Mpeg1/2 algorithmiquement identique à un décodeur C, est plus lent de 1,9 % (pour 30 % de code en moins, langage objet de haut niveau oblige).
L'avenir est à mon avis aux langages objets dont le compilateur est doté d'un algorithme de suppression de la liaison dynamique.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# SmartEiffel
Posté par Ontologia (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 7.
Dans tous les langages objets, l'accès à une méthode spécialisé sur plusieurs classes dans l'arbre d'héritage se fait par une liaison dynamique, plus exactement une VFT (Virtual Function Table).
En gros, on a une structure avec un pointeur sur fonction que l'on peut parfois mettre dans un tableau.
En assembleur ça donne des trucs du genre "call dword ptr [_adresse_de_la_fonction]", ce qui implique :
- Que l'inlining est très limité
- Que le processeur est obligé de vider son cache mais aussi de laisser tomber toutes ses prédictions de branchements.
Donc une chute des performances.
A ma connaissance, tous les langages objets sauf (Smart) Eiffel et Lisaac fonctionnent comme ça.
Avec l'algorithme du produit cartésien de Ole Agesen et Craig Chambers (à peu près innaplicable), l'algorithme de Dominique Colnet est le premier à réussir à supprimer la liaison dynamique.
Un algorithme de prédiction de type détermine les types possibles pour le receveur et les paramètres, ce qui donne lieu à un switch afin de traiter chaque cas.
En plus, on peut enfin faire de l'inlining et de la spécialisation de code.
Le problème de Smart Eiffel, c'est qu'il traite tous les cas de résolution de type, même ceux, qui, dans le code tel qu'on le possède ne pourront jamais survenir.
Lisaac est le premier compilateur à analyser tout son code et de déterminer les types possibles et de ne traiter qu'eux seuls.
Ca permet d'éviter plus de 84 % de switch.
L'inlining est encore facilité, ainsi que la spécialisation de code.
Résultat, un décodeur Mpeg1/2 algorithmiquement identique à un décodeur C, est plus lent de 1,9 % (pour 30 % de code en moins, langage objet de haut niveau oblige).
L'avenir est à mon avis aux langages objets dont le compilateur est doté d'un algorithme de suppression de la liaison dynamique.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker