Co�t polymorphisme

**RockwoodGuitar** · 31/01/2006, 00h18

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** · 31/01/2006, 00h48

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** · 31/01/2006, 04h16

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** · 31/01/2006, 22h34

Envoy� par xxiemeciel

'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** · 01/02/2006, 13h51

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

XXiemeciel

**RockwoodGuitar** · 01/02/2006, 14h09

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

**Selenite** · 01/02/2006, 16h12

Envoy� par xxiemeciel

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** · 01/02/2006, 19h33

Envoy� par Selenite

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** · 01/02/2006, 19h34

Envoy� par RockwoodGuitar

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

je ne crois pas

XXiemeciel

**Jean-Marc.Bourguet** · 01/02/2006, 20h26

Envoy� par xxiemeciel

Envoy� par RockwoodGuitar

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** · 01/02/2006, 20h49

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** · 01/02/2006, 21h26

Envoy� par 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.

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** · 02/02/2006, 01h14

Envoy� par xxiemeciel

Envoy� par Selenite

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** · 02/02/2006, 04h02

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** · 02/02/2006, 09h05

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.

**Caine** · 02/02/2006, 09h19

Envoy� par RockwoodGuitar

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.

Suivant le type de processeur et la vitesse d'acc�s � la ram, une indirection � bien un co�t d'ex�cution. Je suis dans l'embarqu�. Sur un automate avec un 386ex, de la ram � moins de 150 nano seconde de temps d'acc�s, le co�t d'une indirection peu aller jusqu'� 100 ns (acc�s � la m�moire) par indirection. Imagine qu'il faille 10 indirections, tu obtiens 10 * 90 ns = 900 ns! Suivant Si tu n'as qu'une seule fois ce traitement �a va, s'il se retrouve sur un vecteur d'interruption, bonjour la catastrophe!

Envoy� par RockwoodGuitar

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?

Le mieux est de conna�tre la vitesse de la RAM, du processeur, et d�avoir le temps th�orique des instructions assembleurs. C�est de cette mani�re que l�on d�termine � quel endroit on peut se permettre du � mou � dans le traitement.