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++ vitesse: if vs pointeur de methode

vitesse: if vs pointeur de methode

126 réponses
Avatar
Guillaume Desticourt
bonsoir,

je m interroge sur la vitesse d execution entre une comparaison et un
pointeur de methode.
j ai une class dont une methode peut changer de comportement au cours de
la vie du process, mais cela rarement.
je me demandais si je devais avoir une methode unique avec un bloc
if/else ou alors un pointeur de methode sette a la methode qui va bien.
j ai donc ecrit deux petits programmes de test, et la solution if/else
est /visiblement/ plus rapide.
et donc je me demandais:
- est ce que mon test est pertinent?
- pourquoi une telle difference de temps?

les prog ont ete compile sous un linux 2.6 avec g++ 3.3.5

merci,

def.hh
------


#ifndef DEF_HH
# define DEF_HH

#include <stdlib.h>

#define MAX_LOOP 1000000000

class Test;

typedef int (Test::*behavior_t)(void);

class Test
{
public:
Test() :
_test(true)
{
}

int behavior1(void)
{
return 0;
}
int behavior2()
{
return 0;
}

inline bool isTrue(void)
{
return _test;
}
private:
bool _test;
};

#endif

if.cc
-----


#include "def.hh"

int main(void)
{
Test * test = new Test();

for (unsigned long u = 0;
u < MAX_LOOP;
++u)
{
if (test->isTrue())
test->behavior1();
else
abort();
}
return 0;
}


pointer.cc
----------



#include "def.hh"

int main(void)
{
Test * test = new Test();
behavior_t behavior;
if (test->isTrue())
behavior = &Test::behavior1;
else
abort();

(test->*behavior)();


for (unsigned long u = 0;
u < MAX_LOOP;
++u)
{
(test->*behavior)();
}
return 0;
}


Makefile
--------

all: iftest pointertest

iftest: def.hh
g++ -Wall -Werror -O2 if.cc -o iftest

pointertest: def.hh
g++ -Wall -Werror -O2 pointer.cc -o pointertest

clean:
rm -f *.o
rm -f *~
rm -f iftest pointertest


une tarball est - provisoirement - disponible ici:
http://www.freenopen.net/~guillaume/info/prog/source/ifpointerbench-20050720-1755.tar.bz2

--
Guillaume Desticourt
Signaler un problème avec ce contenu

6 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
9 10 11 12 13
Avatar
Jean-Marc Bourguet
Fabien LE LEZ writes:

On 26 Jul 2005 01:14:38 -0700, :

Mais j'avoue que le seul mot qui me convient vraiment, c'est
« sous-programme ». Est-ce du à mon âge ?


Peut-être. J'appartiens à une génération où "sous-programme" signifie
"BASIC" -- je n'ai pas connu d'autre langage qui parle de
sous-programme.


Fortran a des SUBROUTINE.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org


Avatar
Pierre Maurette
Fabien LE LEZ wrote:

Peut-être. J'appartiens à une génération où "sous-programme" signifie
"BASIC" -- je n'ai pas connu d'autre langage qui parle de
sous-programme.


L'assembleur, peut-être.
Pas ceux que je connais (voir plus bas quand même). En fait, on peut

parler de procédure à cause de la directive PROC d'un macro assembleur.
L'assembleur peut répondre à toutes les conventions d'appel. C'est
quand même le vocabulaire du C qui domine.

Je me souviens qu'il fut un temps où l'on parlait aussi de routine et de
subroutine...
Fortran connait les procédures, qu'il sépare en sous-programmes et

fonctions. A part ça, je considèrerais volontier le sous-programme
comme une entité qui appartiendrait au programmeur plus qu'au langage.
Des sections de code qui ne seraient pas nécessairement compilables à
part, pour lesquelles la récupération de l'adresse de retour (s'il en
existe une) ne serait pas automatique. Ou même des bouts de code
copiés/collés de place en place (des macros). Liés à des langages non
naturellement structurés, comme certains Basics ou l'assembleur,
possédant et *utilisant* des goto et autres jump.
Mais c'est personnels, d'autres parleront peut-être de sous-programmes
pour des ensembles plus gros que la fonction (des modules ?).

--
Pour répondre directement: enlever une lettre sur deux
wwaannaaddoooo -> wanadoo

Pierre Maurette


Avatar
kanze
Pierre Maurette wrote:
Fabien LE LEZ wrote:

Peut-être. J'appartiens à une génération où
"sous-programme" signifie "BASIC" -- je n'ai pas connu
d'autre langage qui parle de sous-programme.


L'assembleur, peut-être.


Pas ceux que je connais (voir plus bas quand même).


L'assembleur lui-même, évidemment pas. Tu écris les instructions
machine directement. Mais quand on parle des programmes en
assembleur, sous-programme était assez courant.

En fait, on peut parler de procédure à cause de la directive
PROC d'un macro assembleur.


Ce que j'ai vu pour la première fois avec l'assembleur 8086, en
1979. Je programmais bien en assembleur avant ça.

Il me semble qu'on parlais des « subroutines » dans la doc de
l'autocodeur 1401. Si j'y pense, j'y jetterai un coup d'oeil ce
soir, quand je suis à la maison. (C'est la première machine que
j'ai programmé, et j'ai gardé les manuels comme souvenir. Et la
façon qu'on y linkait un sous-programme, c'est qu'on allait
chercher les cartes avec les sources, et on les ajoutait
derrière tes propres cartes source quand on assemblait le
programme.)

L'assembleur peut répondre à toutes les conventions d'appel.
C'est quand même le vocabulaire du C qui domine.


Aujourd'hui, peut-être. (Mais alors, pourquoi est-ce que Java a
des méthodes, et non des fonctions ?) Mais dans les années
1970, le C n'était pas très répandu.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



Avatar
kanze
Laurent Deniau wrote:
wrote:
Laurent Deniau wrote:

[...]

En principe, quand il n'y a pas d'abus de langage on a:

fonction = resolution statique = appel direct
methode = resolution tardive = appel indirect (pointeur de fonction)
message = resolution dynamique = appel dynamique (dictionnaire +
pointeur de fonction)


Selon qui ? Je ne savais pas que c'était toi qui définissait
ce qui est abus de langage, et ce qui ne l'est pas. Le
problème


Ce n'est pas moi qui definit ces termes, meme si j'essaye ici
de les presenter de maniere "unifiee".


Je m'en doutais un peu. Mais j'aurais voulu savoir tes sources.
Parce que tes définitions ne correspond à rien de ce que j'ai
jamais vu.

C'est un consensus observe dans la terminologie de plusieurs
langages, C++ inclu.


Ce n'est pas la terminologie de C++ (où il n'y a que des
fonctions, virtuelles ou non), ni de Java (où il n'y a que des
méthodes, statiques ou non). Smalltalk parle d'« envoyer un
message » qui est traité par une méthode -- ce n'est donc pas de
là non plus. Lisp (au moins Scheme) parle des fonctions, alors
que la resolution est plutôt dynamique.

Je trouve que des définitions plus ou moins universelles
seraient une bonne chose (et les tiennes sont aussi bien que
n'importe quoi d'autre). Mais actuellement, j'ai l'impression
que c'est le bordel complet.

réel, c'est justement qu'il n'y a pas de consensus. : avant
l'apparition de Java, pour moi, une « méthode », c'était
quelque chose invoquée par « l'envoi d'un message », tandis
qu'une fonction, c'était quelque chose invoquée par un «
appel de fonction ». Mais c'est une définition un peu
circulaire. Enfin, en Java, il n'y a que des méthodes, y
compris les méthodes statiques. Certains donc utilisent «
méthode » pour toute fonction membre ; je crois même que
c'est l'utilisation la plus


La difference, c'est qu'en Java, toutes les fonctions
(membres) ont une invocation virtuelle, y compris les static.
Cf JVM Specs.


Dans la spécification du langage, il y a bien une différence.
C'est ce que voit l'utilisateur.

Si on considère Smalltalk, la plupart des compilateurs arrivent
à résoudre certains envois de message en appel direct de
fonction. Est-ce que la terminologie correcte dépend de l'état
d'optimisation ? À mon avis, non -- elle doit dépendre
uniquement de ce que perçoit l'utilisateur, selon la définition
du langage.

répandue. D'autres, dont moi-même, adjustent les définitions
selon la communité ciblée -- je n'utilise jamais le mot
méthode à propos de C++, mais je n'utilise que le mot
méthode quand je parle de Java.


Tu es libre de porter des oeilleres.

TC++PL3, 12.2.6 virtual function

[...] A virtual member function is sometimes called a method.

C'est ajuste', non?


Dans la norme, elle n'est jamais appelée une méthode.

Je fréquente pas mal de groupes de discussion sur le C++. Je
peux te dire qu'il n'y a pas de consensus sur l'utilisation.
Certains rejette le mot « méthode » complètement, et si on veut
être sûr de se faire comprendre, c'est certainement la façon la
plus sûr. D'autres l'utilisent comme suggère Stroustrup, pour
des fonctions membre virtuelles. Encore d'autres l'utilisent
pour toute fonction membre, voire pour toute fonction, tout
court. Dans la mesure où il n'y a pas de consensus sur sa
signification, et qu'elle semble genait certains, je n'utilise
que le mot « fonction ». Avec les adjectifs qu'il faut, le cas
échéant.

Le probleme, c'est que l'emploi de ces termes impliques une
connaissance (limitee) de la resolution d'appel et donc de
l'implementation, ce qui n'est generalement pas le but.


Le problème, surtout, c'est que cet emploi implique une
connaissance de tes définitions, qui ne sont pas celles des
autres.


Le probleme, c'est que plusieurs communautes essayent de
partager leur culture informatique alors que d'autres
orientees marketing cherche a vendre en utilisant les termes
les plus a la mode, par necessairement approprie dans leur
cas. Ajoute a cela le changement de terminologie entre la
definition et l'invocation dans certains langages (SmallTalk
et Objective-C par exemple) et tu as l'etat de l'art de la
confusion regnante.


Tout à fait. C'est tout ce que je voulais dire.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



Avatar
kanze
Bertrand Motuelle wrote:
wrote:
Fabien LE LEZ wrote:

D'autant que C# concerne principalement le service
marketing. Les gus qui font tout à fait autre chose
(développement de Office par exemple) n'ont rien à voir
là-dedans.


Au moins qu'on lui impose C# d'en haut. Ou simplement que MS
se désintéresse de C++ au point à laisser moribonder le
compilateur (comme fait Sun) ;


Qu'est-ce qui te fais penser que Sun laisse leur compilo C++
mourir ?


Je compare sa vitesse d'évolution à celle des autres
compilateurs.

L'évolution récente (ou plutôt la manque d'évolution récente) ne
me plaît pas. Pendant longtemps, Sun CC était mon compilateur
préféré. Je connais des développeurs chez Sun ; j'en considère
certains prèsque des amis, et j'ai probablement appris plus de
C++ de Steve Clamage que de n'importe où ailleurs. Mais
dernièrement, le compilateur a plutôt stagné comparé aux autres
(g++, VC++, etc.).

Récemment, le dit compilo a fait des progrès considérables
dans la gestion des templates, des fonctions inline, etc. Sun
permet également l'utilisation d'une bibliothèque standard
bien plus performante et complète que celle apparue avec C++
5.0 (d'origine Roguewave) : STLport.


Il le permet. C'est à mon avis déjà une partie du problème. Il y
avait un problème avec la bibliothèque standard. (Ils avaient
mal choisi le fournisseur externe.) La solution, ce n'est pas
vraiment de le réparer. La solution, c'est de dire qu'il existe
une solution de contournement, à partir du logiciel freeware.

(Note que je ne suis pas contre l'utilisation d'un logiciel
freeware dans ce cas, si c'est la solution optimale. Mais alors,
qu'on le fait sérieusement, comme a fait Apple avec g++ : on
contribue en proportion avec ce qu'on en tire. On ne se contente
pas de dire que voilà, ça existe, et pour être gentil, on va
même le bundler avec le produit. Et espérer que les autres font
tout le travail.)

Et un des objectifs affichés est que C++ 5.7 puisse compiler
boost.


Wouah ! Est-ce qu'il y a un autre compilateur dont la dernière
version ne compile pas Boost ?

Le compilateur évolue rapidement dans ce sens, et Sun
contribue à la mise au point des fichiers de configuration de
boost. cf. les messages de Steve Clamage sur le forum du
compilo:
http://forum.sun.com/thread.jspa?threadID#793&tstart=0


Hmmm. Je ne connais pas ce forum. J'y jetterai un coup d'oeil
(ne serait-ce que parce que Steve Clamage y contribue).

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



Avatar
Laurent Deniau
wrote:
Laurent Deniau wrote:
Ce n'est pas moi qui definit ces termes, meme si j'essaye ici
de les presenter de maniere "unifiee".



Je m'en doutais un peu. Mais j'aurais voulu savoir tes sources.
Parce que tes définitions ne correspond à rien de ce que j'ai
jamais vu.


Ce ne sont pas des definitions formelles et comme je le dis plus loin
dans le post (cf ci-dessous),et je dis meme que c'est assez subjectif.
Tu as omit les explications qui suivaient, c'est pas bien ;-). L'aspect
abus de langage faisait reference aux utilisations abusives en
marketing, pas a la formalite des termes ennonces.

[Le probleme, c'est que l'emploi de ces termes impliques une
connaissance (limitee) de la resolution d'appel et donc de
l'implementation, ce qui n'est generalement pas le but. D'ou je pense
une certaine confusion a travers les cultures et les langages suivant le
parti pris de celui qui explique (moi compris ;-) ). Le fait aussi que
les compilateurs sachent dans certaines conditions faire les
optimisation d'appel message -> methode -> fonction -> inline n'aide pas
non plus a etre formel.]

C'est un consensus observe dans la terminologie de plusieurs
langages, C++ inclu.



Ce n'est pas la terminologie de C++ (où il n'y a que des
fonctions, virtuelles ou non), ni de Java (où il n'y a que des
méthodes, statiques ou non). Smalltalk parle d'« envoyer un
message » qui est traité par une méthode -- ce n'est donc pas de
là non plus. Lisp (au moins Scheme) parle des fonctions, alors
que la resolution est plutôt dynamique.


Oui, est-ce que cela enleve le droit de trouver un consensus a partir de
ces terminologies?

Je trouve que des définitions plus ou moins universelles
seraient une bonne chose (et les tiennes sont aussi bien que
n'importe quoi d'autre). Mais actuellement, j'ai l'impression
que c'est le bordel complet.


c'est mon impression.

réel, c'est justement qu'il n'y a pas de consensus. : avant
l'apparition de Java, pour moi, une « méthode », c'était
quelque chose invoquée par « l'envoi d'un message », tandis
qu'une fonction, c'était quelque chose invoquée par un «
appel de fonction ». Mais c'est une définition un peu
circulaire. Enfin, en Java, il n'y a que des méthodes, y
compris les méthodes statiques. Certains donc utilisent «
méthode » pour toute fonction membre ; je crois même que
c'est l'utilisation la plus




La difference, c'est qu'en Java, toutes les fonctions
(membres) ont une invocation virtuelle, y compris les static.
Cf JVM Specs.



Dans la spécification du langage, il y a bien une différence.
C'est ce que voit l'utilisateur.


On parlait de la semantique de l'invocation (via un pointeur pour le
C++). Si celle-ci est resolue systematiquement de maniere virtuelle
(avant optimisation) comme en Java, cela peut-etre suffisant pour
decider de parler de methode systematiquement. Ajoute a cela que Java se
dit simple, et une simplification des termes est alors la bienvenue.
Parce que parler de <fonction membre virtuelle pure constante> toutes
les deux lignes complique passablement la lecture du texte, meme si
celui est plus precis.

Si on considère Smalltalk, la plupart des compilateurs arrivent
à résoudre certains envois de message en appel direct de
fonction. Est-ce que la terminologie correcte dépend de l'état
d'optimisation ? À mon avis, non -- elle doit dépendre


Effectivement non, c'est ce que je suggere dans mon post original (cf
ci-dessus). L'idee serait de ne parler que de la semantique de
l'invocation la plus "dynamique". Les optimisations sont le problemes
des compilateurs et/ou machine virtuelle. Mais ca c'est anti-marketing ;-)

uniquement de ce que perçoit l'utilisateur, selon la définition
du langage.


Pas d'opposition. Suffit d'etre consistant.

Le probleme, c'est que plusieurs communautes essayent de
partager leur culture informatique alors que d'autres
orientees marketing cherche a vendre en utilisant les termes
les plus a la mode, par necessairement approprie dans leur
cas. Ajoute a cela le changement de terminologie entre la
definition et l'invocation dans certains langages (SmallTalk
et Objective-C par exemple) et tu as l'etat de l'art de la
confusion regnante.



Tout à fait. C'est tout ce que je voulais dire.


He bien on y arrive douuuucement ;-)

a+, ld.



9 10 11 12 13