Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Eviter le coût de la résolution de "virtual"

Eviter le coût de la résolution de "virtual"

29 réponses
Avatar
Vincent Richard
Bonsoir,

Soit le programme suivant :

class A
{
public:
virtual void f(const int p) = 0;
};

class B : public A
{
public:
void f(const int p) { /* ... */ }
};

int main()
{
A* a = new B;

for (int i = 0 ; i < 10000 ; ++i)
a->f(i);
}

Je crois savoir qu'à chaque fois que l'on fait un appel à 'f()', une
"recherche" est effectuée pour appeler la fonction correcte selon
l'objet sur lequel on l'appelle. Cette recherche a un coût.

Y'a-t-il un moyen de la limiter, par exemple, en obtenant l'adresse
une première fois (résolution), puis en l'appelant ensuite (simple
appel, sans résolution), ce qui fait que la résolution n'est pas
faite à chaque itération ?

Par exemple :

int main()
{
A* a = new B;
PointeurSurLaFonction pf = ???;

for (int i = 0 ; i < 10000 ; ++i)
(pf)(i);
}

Apparemment, cela ne peut pas être résolu avec les pointeurs sur
fonctions membres :

int main()
{
A* a = new B;

typedef void (A::*FuncPtr)(int);
FuncPtr pf = &A::f;

for (int i = 0 ; i < 10000 ; ++i)
(a->*pf)(i);
}

...puisque dans ce cas, la résolution est évidemment quand même faite.

Je ne sais pas si je suis très explicite...

Merci d'avance pour vos réponses.

Vincent

--
SL> Au fait elle est mieux ma signature maintenant ?
Oui. T'enlève encore les conneries que t'as écrit dedans et c'est bon.
-+- JB in <http://www.le-gnu.net> : Le neuneuttoyage par le vide -+-
Signaler un problème avec ce contenu

9 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Gabriel Dos Reis
Laurent Deniau writes:

| Je travaille sur les champs magnetiques et la supraconductivite, pas
| sur la radioactivite. Rien a craindre meme si j'arrive plus a
| aligner deux mots corrects.

Mais il se peut que tu déclenches une singularité magnéto-conductive
exceptionnelle entraînant une implosion fatale dont il est question
dans la théorie de Kerr-Johnston-Carter. Ce qui a détruit Abydos est,
d'après ce qu'on m'a dit, basé sur un phénomène similaire.

-- Gaby
Avatar
Laurent Deniau
Gabriel Dos Reis wrote:
Laurent Deniau writes:

| Je travaille sur les champs magnetiques et la supraconductivite, pas
| sur la radioactivite. Rien a craindre meme si j'arrive plus a
| aligner deux mots corrects.

Mais il se peut que tu déclenches une singularité magnéto-conductive
exceptionnelle entraînant une implosion fatale dont il est question
dans la théorie de Kerr-Johnston-Carter. Ce qui a détruit Abydos est,
d'après ce qu'on m'a dit, basé sur un phénomène similaire.


Aucun risque, on ne travaille pas dans ce domaine de la supra et en plus ce
n'est pas moi qui fait les manips. Je ne fais qu'analyser les resultats ou faire
des outils pour les analyser.

a+, ld.

--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]

Avatar
kanze
Gabriel Dos Reis wrote in message
news:...
writes:

| Sur ma machine de travail, la différence en coût de l'appel d'une
| fonction vide, non-inline, et de l'ordre de 10.

La difference ou le rapport ?


Le rapport. C-à-d que l'appel (y compris le retour) de la fonction :

int
C::f() const
{
return 5 ;
}

(définit dans une unité de compilation à part, pour éviter
l'optimisation) prenait 10 fois plus de temps si la fonction était
virtuelle que si elle ne l'était pas. Plus, en fait : j'ai les mésures
suivantes sur ma machine (en nanosécondes, pour l'expression i = f(), où
i est une variable membre, compilé avec Sun CC 5.1, option -O4) :

function libre :
inline 5,8
out of line 19,7
fonction membre :
inline 4,9
out of line 1,8
virtuelle 75,1

La différence est énorme. En revanche, il ne faut pas perdre de vue les
valeurs absolues, et les rapports par rapport à d'autres choses. Donc,
par exemple, même l'appel virtuelle prend moins de temps que la
multiplication de deux int. Du moment qu'on fait un calcul non trivial
dans la fonction, le temps de calcul risque d'être préponderant, même
avec les fonctions virtuelles -- gagner une facteur de 10, voire plus,
sur quelque chose qui n'occupe qu'1% du temps ne rapporte rien.

Enfin, évidemment, ces mésures ne vaut que sur une machine donnée. Les
différences de temps dépendent largement de la gestion du pipeline et de
la prévision des branchements. Choses qui varient énormement d'un
processeur à l'autre, même à l'intérieur de la même architecture.

(En passant, ça ne me gènerait pas du tout que quelqu'un jette un coup
d'oeil au code (le benchmark FunctionCall sur ma site), juste pour voir.
Ça m'est arrivé déjà une fois de faire une bêtise stupide dans un
benchmark, qui faussait toute la mésure.)

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Avatar
Gabriel Dos Reis
--=-=- Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

writes:

| Tandis que chez moi, sur mon Sparc du travail, la différence rélative
| est énorme. Et il y a bien des opérations de base, surtout sur des
| flottants, qui sont nettement plus rapide qu'un appel virtuel. Alors, si
| la fonction fait quelque chose du genre « return a * x + b ; » avec des
| flottants (float ou double), on resentira bien la différence entre
| virtuel et non virtuel. (À condition que la fonction soit appelée dans
| une boucle serrée, évidemment.)

--=-=- Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable


J'ai lu récemment des papiers écrits par des physiciens (ou
numériciens je ne sais plus) qui faisaient l'éloge de la programmation
orintée objet (en caricaturant un peu, « votre solveur est Bon » parce
qu'il utilise l'orientation objet) en montrant comment il est facile
de concevoir un solveur en demandant que l'équation soit représentée
par une fonction virtuelle. Évidemment, il n'y a pas eu de discussion
de performance.

-- Gaby

--=-=-=--
Avatar
Gabriel Dos Reis
Gabriel Dos Reis writes:

| [1 <text/plain; iso-8859-1 (8bit)>]

[...]

| [2 <text/plain; iso-8859-15 (quoted-printable)>]

Aaarg, j'ai deux mots à dire (encore!) à Gnus.
Excusez-moi.

-- Gaby
Avatar
Alain Naigeon
"Laurent Deniau" a écrit dans le message news:



Gabriel Dos Reis wrote:
Laurent Deniau writes:

| Je travaille sur les champs magnetiques et la supraconductivite, pas
| sur la radioactivite. Rien a craindre meme si j'arrive plus a
| aligner deux mots corrects.

Mais il se peut que tu déclenches une singularité magnéto-conductive
exceptionnelle entraînant une implosion fatale dont il est question
dans la théorie de Kerr-Johnston-Carter. Ce qui a détruit Abydos est,
d'après ce qu'on m'a dit, basé sur un phénomène similaire.



Abydos svp ?? Je le trouve pas dans la norme ;-)

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Strasbourg, France


Avatar
James Kanze
Gabriel Dos Reis writes:

|> writes:

|> | Tandis que chez moi, sur mon Sparc du travail, la différence
|> | rélative est énorme. Et il y a bien des opérations de
|> | base, surtout sur des flottants, qui sont nettement plus rapide
|> | qu'un appel virtuel. Alors, si la fonction fait quelque chose du
|> | genre « return a * x + b ; » avec des flottants (float ou
|> | double), on resentira bien la différence entre virtuel et non
|> | virtuel. (À condition que la fonction soit appelée dans une
|> | boucle serrée, évidemment.)

|> J'ai lu récemment des papiers écrits par des physiciens (ou
|> numériciens je ne sais plus) qui faisaient l'éloge de la
|> programmation orintée objet (en caricaturant un peu, « votre
|> solveur est Bon » parce qu'il utilise l'orientation objet) en
|> montrant comment il est facile de concevoir un solveur en demandant
|> que l'équation soit représentée par une fonction virtuelle.
|> Évidemment, il n'y a pas eu de discussion de performance.

Il y a sans doute des applications où la performance n'a pas trop
d'importance. Encore j'aurais imaginé qu'un solveur n'en fasse pas
partie. Il y a aussi certainement des machines (et des compilateurs)
où la différence du temps n'est pas aussi élevée. C'est
certain que pour ce genre de chose, les fonctions virtuelles sont
idéales, quand les performances les permettent.

En passant, je n'ai rien vu de ton texte dans Google -- seulement la
partie que tu avais citée. (Pas de problème avec GNU's et une
connexion directe au serveur NNTP, en revanche.)

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Avatar
James Kanze
Gabriel Dos Reis writes:

|> James Kanze writes:

|> | Gabriel Dos Reis writes:

|> | |> writes:

|> | |> | Tandis que chez moi, sur mon Sparc du travail, la
|> | |> | différence rélative est énorme. Et il y a bien des
|> | |> | opérations de base, surtout sur des flottants, qui sont
|> | |> | nettement plus rapide qu'un appel virtuel. Alors, si la
|> | |> | fonction fait quelque chose du genre « return a * x + b ;
|> | |> | » avec des flottants (float ou double), on resentira bien
|> | |> | la différence entre virtuel et non virtuel. (À
|> | |> | condition que la fonction soit appelée dans une boucle
|> | |> | serrée, évidemment.)

|> | |> J'ai lu récemment des papiers écrits par des physiciens
|> | |> (ou numériciens je ne sais plus) qui faisaient l'éloge
|> | |> de la programmation orintée objet (en caricaturant un peu,
|> | |> « votre solveur est Bon » parce qu'il utilise
|> | |> l'orientation objet) en montrant comment il est facile de
|> | |> concevoir un solveur en demandant que l'équation soit
|> | |> représentée par une fonction virtuelle. Évidemment,
|> | |> il n'y a pas eu de discussion de performance.

|> | Il y a sans doute des applications où la performance n'a pas
|> | trop d'importance.

|> je n'en doute pas une seule seconde.

En fait, il y a un émoticon qui s'est perdu quelque part lorsque
j'éditais mon text. Ma phrase ci-dessus est à prendre avec un peu
d'ironie.

|> | Encore j'aurais imaginé qu'un solveur n'en fasse pas partie. Il
|> | y a aussi certainement des machines (et des compilateurs) où la
|> | différence du temps n'est pas aussi élevée. C'est certain
|> | que pour ce genre de chose, les fonctions virtuelles sont
|> | idéales, quand les performances les permettent.

|> moin point était que certains papiers académiques ne se
|> préoccupent pas de la performance -- au pire on invoquera la loi
|> de Moore et basta.

Ce qui m'inquiète un peu.

Pendant longtemps, il y avait trop d'insistance sur les performances --
on voyait des gens se plaidre du coût de l'appel virtuel d'un
fonction qui lisait un caractère du clavier, ou des choses de ce
genre. Du coup, moi, j'ai beaucoup râlé qu'on mettait trop
d'importance sur la performance. Alors, aujourd'hui, même si ce
problème n'est pas disparu, je constate de plus en plus le contraire ;
que les gens veulent ignorer la performance même où elle est
importante. Alors, je commence à râler dans l'autre sens.

Au niveau applicatif, on ne s'occupe de la performance qu'avec des
indications du profiling. En revanche, on ne néglige pas à
spécifier la performance globale attendue, et quand on n'y arrive
pas, on sort bien le profiler. (On évite aussi des bêtises. Ce
n'est pas parce que la performance n'est pas très importante que je
vais utiliser un tri à bulle, tout en sachant qu'il y aurait
plusieurs millions d'éléments à trier.)

Quand on écrit quelque chose où on n'a pas accès au programme
final complet, comme une bibliothèque, la question est un peu plus
complex, et souvent, il faut faire des suppositions sur l'utilisation.
AMHA, quelqu'un qui écrivait une bibliothèque standard où
std::vector<>::operator[] n'est pas inline manque de bon sens, par
exemple.

Et quand on écrit un article, surtout qui se traite d'un problème
dans un domaine où la performance est souvent importante, manque de
responsibilité s'il n'indique pas les implications de sa solution sur
la performance (quitte a dire par la suite qu'il ne crois que ça ne
serait pas signifiant dans la plupart des utilisations prévues).

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Avatar
Samuel Krempp
le Sunday 14 September 2003 18:23, écrivit :
hmm, je suis incapable de fournir une explication qui tient la route.

-- Gaby


j'ai déja remarqué des effets bizarre avec knode. de temps en temps -j'ai
l'impression que c'est seulement quand le texte cité est gros, ou ..-
ton texte est mis à part du texte cité (sauf d'éventuels bouts que tu mets
entre les lignes citées) comme un attachment.

et le header type indique dans ce cas :
type: multipart/mixed; boundary="=-=-="

C'est étrange que gnus décide parfois d'envoyer tes articles en multipart.
--
Sam

1 2 3