Discussion :

[RockwoodGuitar]

Bonjour,

j'ai eu ouïe dire que l'utilisation du polymorphisme avait un coût temporel élevé - parce qu'il fallait déterminer dynamiquement le type de l'objet appelant la fonction membre.

En m'informant à ce sujet, je n'ai trouvé que des articles parlant du concept de "table de fonction virtuelle", qui n'implique qu'une indirection, et est donc extrêmement rapide à résoudre.

Je voudrais utiliser le polymorphisme dans un contexte temps-réel, aussi il me faut maîtriser parfaitement le temps pris par les mécanismes sous jacents. Quelqu'un peut-il m'aiguiller à ce sujet? Peut-être me donner des références où trouver de l'information?

Merci d'avance,

Antoine.

[Luc Hermitte]

Mettre en oeuvre le mécanisme de décision retardée (si je puis dire) sans passer par le polymorphisme (d'inclusion, sous entendu ici) va avoir un coût équivalent, pour une maintenabilité déplorable.
Il n'y a pas de sens à critiquer les perfs du polymorphisme en ignorant le contexte des problèmes qu'il résoud. Cela a déjà été discuté ici. Une bonne référence reste le document n1666 sur le site du commité de standardisation (google pour l'adresse!).

De plus, ce n'est pas une petite indirection qui va faire s'éfrondrer un système temps réel.

[xxiemeciel]

Salut,

j'au fait beauocup de tests de performances a ce niveau et la perte de performance est peut etre vrai pour un seul appel (le premier) mais pour les suivant il n'y a pas vraiment de cout, donc en moyenne c'est plutot negligeable.

XXiemeciel

[Luc Hermitte]

'au fait beauocup de tests de performances a ce niveau et la perte de performance est peut etre vrai pour un seul appel (le premier) mais pour les suivant il n'y a pas vraiment de cout, donc en moyenne c'est plutot negligeable.

La perte de performance par rapport à quoi ? 3 if en cascade, un switch, une indirection au travers d'une table de pointeurs de fonctions ?

[xxiemeciel]

a l'appel d'une fonction via une interface virtuel contre l'appel direct a la fonction sur son type reel.

XXiemeciel

[RockwoodGuitar]

Ce temps d'appel ne dépend pas de l'implémentation du compilo?

[Selenite]

a l'appel d'une fonction via une interface virtuel contre l'appel direct a la fonction sur son type reel.

Comme disait Luc, ça n'a aucun sens de comparer ces deux choses là puisqu'elles ne répondent pas au même besoin. C'est comme si tu comparais la modification directe d'une variable et le modification via un pointeur. Tu n'a en général pas le choix d'utiliser l'un où l'autre : la question de la performance ne se pose pas.

[xxiemeciel]

la question de la performance ne se pose pas.

je suis absolument pas d'accord sur ce point mais ce n'est pas le lieu pour en debattre.

XXiemeciel

[xxiemeciel]

Ce temps d'appel ne dépend pas de l'implémentation du compilo?

je ne crois pas

XXiemeciel

[Jean-Marc.Bourguet]

Ce temps d'appel ne dépend pas de l'implémentation du compilo?

je ne crois pas

Rien n'impose l'utilisation d'une table de fonctions virtuelles. D'autres techniques sont possibles, isolément ou en combinaison.

De toute façon, sur des processeurs un peu moderne il y a d'autres facteurs qui entrent en compte. Un cas extrème: je parie qu'un appel virtuel prédit dont la destination se trouve dans le cache sera plus rapide qu'un appel normal dont la destination se trouve swappée sur disque :-)

[JolyLoic]

As-tu un pointeur sur ces autres méthodes J'en entends parler depuis un bout de temps, mais ne les ai jamais vues.

[Jean-Marc.Bourguet]

As-tu un pointeur sur ces autres méthodes J'en entends parler depuis un bout de temps, mais ne les ai jamais vues.

Dans le cadre de C++: http://gcc.gnu.org/ml/gcc/2006-01/msg00117.html

Je me souviens avoir lu la description de la méthode utilisée par un compilateur eiffel (peut-être SmallEiffel avant qu'il ne devienne SmartEiffel) et il me semble qu'il y avait une assignation globale lors de la compilation, possible uniquement quand tout le programme est connu. De ce que je me souviens, plutot qu'un pointeur vers la vtable, les objets sont taggés avec des petits entiers et le compilateur génère une fonction qui fait un switch sur cet id.

Il me semble qu'une méthode d'assignation globale est utilisée par le compilateur java de GCC, mais au démarrage, pour les interfaces.

Naturellement, les techniques plus coûteuses en cpu utilisées dans des langages comme SmallTalk ou Python sont aussi utilisables en C++.

Dans le cadre du C++, les seules variations qui me semblent vraissemblables sont les optimisations comme celle de GCC, basées soit sur une analyse statique soit sur du retour de profiling, et utilisant des vtables en dernier recours.

A propos de l'analyse statique, il me semble me souvenir que dans le cas du compilateur Eiffel, celui-ci déterminait qu'une proportion non négligeable des appels n'était pas virtuel. Je ne sais pas dans quelle mesure l'effet serait le même en C++.

Des méthodes plus coûteuses ne sont pas totalement inenvisageables, elles offrent généralement un compromis différent. Si je me souviens bien, Borland C++ avait une méthode alternative d'implémentation des virtuelles où le code cherchait dans plusieurs tables. L'avantage est quand on a beaucoup de fonctions virtuelles qu'on supplante relativement rarement d'occuper moins de mémoire. C'était utilisé dans un cadre où chaque événements de Windows avait un membre correspondant. Comme c'était une extension, il y avait une syntaxe non standard; je ne me souviens plus des détails au point de pouvoir dire s'il y a moyen de se servir de la technique pour une implémentation conforme.

[Luc Hermitte]

la question de la performance ne se pose pas.

je suis absolument pas d'accord sur ce point

Hum, nous ne sommes donc pas d'accord ^^

mais ce n'est pas le lieu pour en debattre.

Pas si sûr. Entre certains documents simplistes (plutôt rares, du moins là où je vais), et des a priori qui refusent l'OO sous prétexte que c'est plus lent sans se poser la principale question : "mais de quelle fonctionnalité a-t-on besoin?", on se retrouve dans des débats stériles et suréalistes qui sont complètement à côté de la plaque. A voir la question de l'OP, il me semble avoir été confronté à ces a priori.

J'imagine que certains (pas me demander des noms, je n'en ai pas) penseront qu'au fond si la liaison tardive via "virtual" ne coute pas grand chose alors autant mettre des "virtual"s partout. Ce qui est n'importe quoi. Sérieusement. Une telle approche est par exemple difficilement compatible avec les sémantiques de valeur (que ne supportent d'ailleurs pas certains langages qui ont supposé "virtual" systématique par défaut), pour l'exemple trivial.

Une vision que j'ai déjà croisée, c'est mettre "virtual" partout, comme ça si il faut dériver, alors c'est immédiat. Ce qui AMHA est une approche hybride entre la naiveté et l'irresponsabilité. Si on ne réfléchit pas à l'avance des points de variations pour notre système, il est peu probable que l'on puisse les intégrer juste en rajoutant un virtual sur une fonction ; on sera ammené à réaliser du refactoring un peu plus profond que cela. Si au contraire on y a réfléchi, et que ça colle, alors le virtual est justifié, et on pinaille pas sur les performances qui sont alors complètement HS vu les alternatives disponibles (cascades de if, switch, tables d'indirection, ...).

Bref, cette redite pour dire qu'en fait le débat de la pertinence de la virtualité est difficilement HS quand on se pose la question des performances de la virtualité suite à des ouïe-dire. Ce sont deux choses que je trouve intimement liées.

Sur un système TR, les perpétuelles (ré)allocations de mémoire et autres copies inutiles me semblent bien plus pertinentes à explorer -- loin derrière la compléxité des algos, les éventuels interblocages, ...

[xxiemeciel]

je suis d'Accord, en tout cas personnellement je n'ai jamais constaté de cout important lié au polymorphisme

et pour information les tests que l'on m'.avait demandé de faire était justement pour annuler tout les oui-dire et autre prejugé sur la virtualité que certains programmeur assez agé avait tendance a defendre becs et ongles.

Xxiemeciel

[Matthieu Brucher]

Pour moi, le polymorphisme est surtout important pour le fontionnement EST-UN. Si c'est du EST-IMPLEMENTE-SOUS-LA-FORME-DE, c'est moisn évident qu'il faut dériver. En tout cas, je n'utilise que rarement des virtual sans que je ne veuille réutiliser cette fonction dans la dérivée à partir de la classe parente, et encore, juste quand je change d'architecture.