De la rapidité du code

Bonjour,

A propos des performances j ai une question qui me chagrine. Voici un exemple simple:
si dans une methode appelee frequemment j ai par exemple:

• n traitements independants

• chaque traitement sera effectue en fonction de son activation et celle ci est connue au depart

• Chaque traitement prend les meme donnees en entree

Vaut - il mieux un code comme le suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

void method(...) { if(traitement_1_actif) { traitement_1(...); } ....... if(traitement_n_actif) { traitement_n(...); } }

---

mais j ai peur que tous ces test a effectuer ne ralentissent le code

ou alors l autre alternative que je vois est la suivante:
tous les traitements implementent une interface commune etant donne qu ils utilisent les memes entree

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

constructeur(....) { // m_traitements est un vecteur de traitement membre de la classe if(traitement_1_actif) { m_traitements.push_back(traitement_1); } ....... if(traitement_n_actif) { m_traitements.push_back(traitement_n); } }   void method(....) { // ApplyTraitement est un objet fonction permettant de faire passer les donnees aux traitements du vector for_each(m_traitements.begin(),m_traitements.end(),applyTraitement(...)); }

---

J ai tendance a trouver la deuxieme solution plus elegante mais ce que je cherche avant tout c est l efficacite en terme de temps d execution...
selon vous y en a t il une meilleure que l autre ? ou voyez vous un autre moyen plus efficace ?

Personnellement, en matière d'optimisation, en plus des règles traditionnelles, j'utilise une bibliothèque qui me simplifie grandement la vie et est très performante : QT4.
En effet, j'ai moins de code à écrire, donc moins de risque de perte de performances. L'API est très complète. Il y a un designer qui produit du code relativement propre qui me permet de faire des interfaces rapidement avec d'excellentes performances.
A cela s'ajoute le fait que la gestion du multi-threading est particulièrement efficace, ce qui n'est pas négligeable en matière de performances.

En gros : une bonne API, du code léger mais efficace et le tour est joué.

Citation:

---

Envoyé par LeGreg

les operateurs binaires operent sur les representations binaires
des nombres. Point.

---

Attention, il ne faut surtout pas confondre "opérateur binaire" et "opérateur agissant sur la représentation binaire" !
Par exemple, ~ est un "opérateur agissant sur la représentation binaire" mais est unaire car ne prend qu'une opérande.
En revanche, * et / sont binaires car ils prennent deux opérandes.

Salut tout le monde,
J'ai vu dans les premières pages qu'il fallait régulièrement bencher son code, mais vous le faites comment?
Avec un clock() ?
Merci

J'aurais une petite question :

quelle différence entre int x (65) et int x = 65 ?

Est-ce que ça a le même effet que ça :

MaClasse:MaClasse ()
: x (65) <---- Ca ?
{
}

J'autre part, j'ai vu sur les papiers du prochain standard une rvalue référence, qui permettrait de faire ça :

MaClasse && operator + (MaClasse obj1, MaClasse obj2)
{
return MaClasse (obj1.x + obj2.x, obj1.y + obj2.y);
}

Sans l'appel à un constructeur de copie ? Comme ça se fera internement (ça se dit ?). Provoquera t'il une amélioration des perfs que ce qui se passe actuellement (car d'après ce que j'ai compris, dans les cas comme ci-dessus, le compilo utilise l'optimisation RVO qui annule un peu cette surcharge ?

Salut,

Pour les types de base ((unsigned)char, (unsigned) int, (unsigned) float, (unsigned) double etc), il n'y a pas de différence entre le fait d'utiliser la liste d'initialisation et celui de faire l'initialisation dans le corps du constructeur.

Par contre, là où la différence apparait, c'est dans le cadre où le membre à initialiser est une classe ou une structure.

En effet, en mettant que l'on aie une classe du genre de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

class Membre { public: Membre(){} Membre(int i, float j) { /* ici, ca ne change pas grand chose */ _i=i; _j=j; } void SetI(int i){_i=i;} void SetJ(float j){_j=j;} int GetI(){return _i;} float GetJ(){return _j;} private: int _i; float _j; };

---

qui doit servir de membre dans la classe

Code:

---

1 2 3 4 5 6 7 8 9 10

class MaClasse { public: MaClasse(Membre& m); MaClasse(int i, float j); /*...*/ private: Membre mem; };

---

Le fait d'utiliser la liste d'initialisation apportera un gain de temps sous la forme de

Code:

---

1 2 3 4 5 6 7 8

MaClasse::MaClasse(Membre& m):mem(m){}/* utilise   * Membre::Membre(Membre&)   */ /* ou */ MaClasse::MaClasse(int i, float j):mem(i,j){}/* utilise   * Membre::Membre(int i, float j)   */

---

par rapport aux constructeurs sous les formes de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

MaClasse::MaClasse(Membre& m) /* utilise Membre::Membre() */ { mem.SetI(m.GetI());/* il faut encore initialiser les valeurs de mem */ mem.SetJ(m.GetJ()); } /* ou */ MaClasse::MaClass(int i; float j)/* utilise Membre::Membre() */ { mem.SetI(i);/* il faut encore initialiser les valeurs de mem */ mem.SetJ(j); }

---

pour la simple raison que, les versions utilisant les liste d'initialisation se contenteront de l'appel du constructeur qui va bien selon le cas (par copie, ou en fournissant les valeurs nécessaire) alors que les autres versions vont:

• Utiliser des valeurs par défaut pour le constructeur (généralement 0 pour _i et 0.0f pour _j dans l'exemple)
• devoir assigner, pour chacun des membre de la classe membre (ici _i et _j) la valeur que l'on veut leur donner

Citation:

---

Pour les types de base ((unsigned)char, (unsigned) int, (unsigned) float, (unsigned) double etc), il n'y a pas de différence entre le fait d'utiliser la liste d'initialisation et celui de faire l'initialisation dans le corps du constructeur.

---

C'est faux.
Si le type est construit avec new, alors toutes ses variables membres qui sont des types de base seront initialisés à 0.

Citation:

---

Envoyé par loufoque

C'est faux.
Si le type est construit avec new, alors toutes ses variables membres qui sont des types de base seront initialisés à 0.

---

Heuuu, faut il rappeler que le sujet et "de la rapidité du code", et que ton intervention n'a donc pas de sens de ce point de vue.

Mon intervention étant à prendre dans le sens que j'ai expliqué: si le membre est d'un type primitif, il n'y aura pas de différence du point de vue de la rapidité d'exécution entre le fait d'utiliser une liste d'initialisation ou non. Par contre, si l'on veut initialiser un membre qui n'est pas strictement un type primitif, ce sera plus rapide d'exécution d'utiliser la liste d'initialisation, et sur ce coup là, rien n'est faux ;)

Citation:

---

si le membre est d'un type primitif, il n'y aura pas de différence du point de vue de la rapidité d'exécution entre le fait d'utiliser une liste d'initialisation ou non

---

Je viens pourtant de t'expliquer que non.
Avec ton code, par exemple, _i et _j peuvent d'abord être initialisées à 0 avant que les valeurs i et j y soient assignées.
Alors que si tu utilisais les listes d'initialisations, _i et _j seraient directement initialisées à la valeur voulue.

Citation:

---

Par contre, si l'on veut initialiser un membre qui n'est pas strictement un type primitif, ce sera plus rapide d'exécution d'utiliser la liste d'initialisation, et sur ce coup là, rien n'est faux

---

Ce n'est pas qu'une question de rapidité, c'est aussi une question de sémantique. Initialiser une variable ce n'est pas la même chose que d'assigner une valeur à une variable.
De plus, toutes les variables ne peuvent pas nécessairement s'initialiser par défaut.

Citation:

---

Envoyé par loufoque

C'est faux.
Si le type est construit avec new, alors toutes ses variables membres qui sont des types de base seront initialisés à 0.

---

Ca aussi, c'est faux.
Le constructeur par défaut est appelé, et les types de bases ne sont initialisés à 0 qu'en mode debug.

En mode Debug sous quel plate-forme ?
C'est totalement contre-productif d'initialiser à zéro en mode Debug. Des valeurs telles que 0xCCCCCCCC sont plus utiles...

Avec GCC par exemple, même chose pour Visual, ...

Citation:

---

les types de bases ne sont initialisés à 0 qu'en mode debug

---

C'est quand même fou.
Je vais donc répéter pour une troisième fois, et citer le standard pour ceux qui ne veulent pas me croire.

Les types de base sont initialisés à 0 quand on utilise new.
Par exemple

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#include <iostream>   struct Foo { int value; };   int main() { Foo v1; int t; Foo* v2 = new(&t) Foo(); Foo* v3 = new Foo();   std::cout << v1.value << std::endl; std::cout << v2->value << std::endl; std::cout << v3->value << std::endl;   delete v3; }

---

affichera dans le premier cas une valeur indéfinie, et dans les deux autres 0.

Voir paragraphe 5.3/16 de N2284.

Encore pire dans ce cas.

Citation:

---

Envoyé par loufoque

Citation:

---

Pour les types de base ((unsigned)char, (unsigned) int, (unsigned) float, (unsigned) double etc), il n'y a pas de différence entre le fait d'utiliser la liste d'initialisation et celui de faire l'initialisation dans le corps du constructeur.

---

C'est faux.
Si le type est construit avec new, alors toutes ses variables membres qui sont des types de base seront initialisés à 0.

---

Tu confonds. Si il y a des constructeurs -- et si c'est pas un POD, il en faut, éventuellement généré automatiquement -- new va appeller un de ceux-ci, et dans ce cas les membres d'un type de base non présents dans la liste d'initialisation ne sont pas initialisés. Pour les POD sans constructeur, effectivement new fait une initialisation à 0.

Je crois que dans le cas de VC++ c'est le cas depuis la version 2005 seulement.
Sinon je viens d'apprendre aujourd'hui que les types de bases étaient initialisés à zéro s'ils étaient statiques.

Visual Studio suit (pour une fois) les recommendations et ne fait (par défaut) aucune initialisation lors d'un 'new' d'un objet avec constructeur, à part celle indiquée dans la liste d'initialisation.

Il existe un flag du compilateur, qui peut le forcer à remplir la mémoire par (de mémoire) 0xCD, flag utilisé en mode "debug", et qui permet de trouver bien vite les bugs (bien plus vite qu'une initilalisation à 0 en tout cas).

Il se peut qu'en mode "release" l'initialisation par affectation dans le constructeur soit identique à celle par la liste d'initialisation, j'avoue n'avoir jamais eu à le vérifier (pas encore eu de profiler me montrant du doigt un constructeur à optimiser).

En cherchant des infos la dessus, je découvre que, d'apres la MSDN, le standard fait une distinction entre:

Code:

---

int *i = new int;

---

et

Code:

---

int *i = new int();

---

l'initialisation de *i a 0 ne se ferait que dans le 2eme cas...
http://msdn2.microsoft.com/en-us/lib...y9(VS.80).aspx

8O

VC++ 2003 respectait cela uniquement pour les types scalaires. VC++ 2005 le respecte aussi pour les classes:
http://msdn2.microsoft.com/en-us/lib...8k(VS.80).aspx

Aurélien > De manière analogue, si on écrit int test (), test semble aussi avoir une valeur par défaut (chez moi c'est 1).

Si tu écris int test(), tu déclareras une fonction renvoyant un int, pas une variable ;)

Tu es sur de ne pas te tromper ?
http://c.developpez.com/faq/cpp/?pag..._list_list_fct

Ah oui en effet, d'où le warning qui s'affichait qui disait que ça renvoyait toujours true :p.

Par contre si j'ai une fonction template avec un type T, si c'est entier, un entier flottant... Je peux faire x = T(); et x vaut 0. Donc logiquement je peux faire int x = int() ?

Si ça marchait comme ça, ça se saurait. Tu ne peux pas assurer que la variable sera initialisée à 0.

Ah bon ? Pourtant ça a toujours bien marché dans mes fonctions templates quand je faisais ça avec des types primitifs, sur mes deux compilos.

Personnellement, sachant que dans certains cas, ça ne donne pas la bonne réponse - mode debug ou autres -, et prévoir ce genre de chose dans sa bibliothèque est indispensable, donc traits et quoiqu'il arrive le problème est réglé car résolu explicitement.

Citation:

---

Envoyé par Bakura

Par contre si j'ai une fonction template avec un type T, si c'est entier, un entier flottant... Je peux faire x = T(); et x vaut 0. Donc logiquement je peux faire int x = int() ?

---

Oui. C'est une 0-initialisation (j'ai oublié le terme exact) connue et abondament utilisée dans le mode merveilleux des templates.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#include <iostream>   int main (int argc, char **argv) { int i = int(); // inverser ne change rien int j;   std::cout << "i:" << i << std::endl;; std::cout << "j:" << j << std::endl;; return 0; }

---

(compilé avec GCC-cygwin (make en fait) sans option particulière (ni -g, ni -O; qui au demeurant ne changent pas grand chose))

Code:

---

1 2 3 4

F:/cygwin/bin/bash.exe -c "./0-init.exe " i:0 j:1628821313 Hit any key to close this window...

---

Ok donc c'est bien ça. Je me disais bien que je l'avais déjà vu plusieurs fois le coup du T() dans du code template :).

Waouuaaaa Quels posts ... :D
Alors les gourous, comment mieux optimiser cela :yaisse2:
Ici, les millisecondes prennent beaucoup d'importance.

http://www.developpez.net/forums/sho...d.php?t=366832

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

// #include <cv.h> #include <highgui.h> #include <stdio.h> #include <cvcam.h> // int frame=0; // void callback(IplImage* img) { int i,j,k,x,y; int iwd=img->widthStep; char *idt=img->imageData; int channels = img->nChannels; double t1=cvGetTickCount( ); frame++; for (x=0;x<320;x++) { for (y=0;y<240;y++) { idt[y*iwd+x*channels]=0; // Pixel Bleu //idt[y*iwd+x*channels+1]=0; // Pixel Vert //idt[y*iwd+x*channels+2]=0; // Pixel Rouge } } printf("Temps 1 %d %f \n",frame,cvGetTickCount( )-t1); }   int main( int argc, char** argv ) { int ncams = cvcamGetCamerasCount( ); cvcamSetProperty(0, CVCAM_PROP_ENABLE , CVCAMTRUE); cvcamSetProperty(0, CVCAM_PROP_CALLBACK ,(void *)callback);   if( !cvcamInit() ) return 0; cvcamStart();   cvWaitKey(0); cvcamStop(); cvcamExit(); }

---

A part remplacer les x++ et y++ par ++x et ++y et remplacer :

Code:

---

1 2 3 4 5 6 7 8 9 10

for (x=0;x<320;x++) { for (y=0;y<240;y++) { idt[y*iwd+x*channels]=0; // Pixel Bleu //idt[y*iwd+x*channels+1]=0; // Pixel Vert //idt[y*iwd+x*channels+2]=0; // Pixel Rouge } }

---

par

Code:

---

1 2 3 4 5 6 7 8 9 10

for (x=0;x<320;++x) { int xMult = x * channels; for (y=0;y<240;++y) { idt[y*iwd+xMult]=0; // Pixel Bleu //idt[y*iwd+x*channels+1]=0; // Pixel Vert //idt[y*iwd+x*channels+2]=0; // Pixel Rouge } }

---

Je ne vois pas, et puis le coup du ++x et x++ je ne pense pas que tu gagnes beaucoup, et le coup de calculer l'expression à l'extérieur de la boucle plutôt qu'à l'intérieur (parceque dans ton second for, le x*channels restera le même durant les 240 itérations), mais je pense que le compilo est assez intelligent pour faire cette optimisation lui même. Sinon, si tu ne modifies pas ton objet img, tu pourrais déclarer comme un pointeur constant (const IplImage * img).

Sinon, si tu fais du C++, remplace printf par cout. Ca va rien améliorer mais c'est tout de suite plus beau :aie:

Et peut-être permuter les deux boucles pour éviter les cache miss.

Le tutorial de GIL explique bien comment optimiser ce genre de choses.

@Bakura.

Mince, j'ai loupé le coup du calcul a l'extérieur de la boucle Y. Merci. :D
Le "printf n'est pas définitif mais c'est en effet une idée.
Le compilateur ou plutot l'IDE c'est DEV C++ ou Code::Block. Le compilateur : MingW ou Gcc.
Cela dit, comme tu le sais sans doute, Code::Block peut s'interfacer de plus avec OpenWatcom, Borland C++ 5.5, Visual C++ Toolkit 2003. Un de ces compilos est sans doute le meilleur?. Lequel?

"Sinon, si tu ne modifies pas ton objet img, tu pourrais déclarer comme un pointeur constant (const IplImage * img)."

Dans ce traitement l'image est modifiée mais l'idée est "mémorisée" pour les autres cas. :P

@HanLee

"Et peut-être permuter les deux boucles pour éviter les cache miss."
Je suis largué. C'est presque du Chinois pour moi :D :D :D

@loufoque

Merci. Super lien :P

Jean-Pierre.

Il faut faire attention avec les i++ et les ++i dans un for il n'y a pas de problème mais dans un while c'est autre chose :

Code:

---

1 2 3 4 5 6 7 8

int i = 10; while(i--) cout << i << endl; i = 10; cout << endl; while(--i) cout << i << endl;

---

Citation:

---

Envoyé par console

9
8
7
6
5
4
3
2
1
0

9
8
7
6
5
4
3
2
1

---

Normal mais il faut juste ne pas l'oublier parce qu'en lisant le post j'ai entendu partout remplacer ça par ça truc par truc mais il faut toujours considérer le context... Voilà

Un truc non abordé...
On peut écrire cela :

Code:

---

1 2 3 4

for (i=0, j=0 ; i<MAX ; i++, k+=4) { //du code }

---

Mais est-ce mal :mrgreen: ?
J'avoue ne pas trouver grand chose à ce sujet...

Il faut juste que i et k soient du même type.

Ah, mais alors, pourquoi ?
J'aimerais bien avoir des détails à ce sujet...

C'est comme ça, il faut que le retour de chaque instruction dans une instruction avec des ',' soit du même type.

C'est valable uniquement pour les boucles ou pour tout le reste ?

Si c'était valable pour le reste, une instructionfree(ptr), ptr=NULL; ne compilerait pas...

Autre question, doit-on essayer de remplacer certaines multiplications par des valeurs immédiates, par des additions/shift ?
Exemple :

Code:

---

x = -x1+3*x2+28*x3-3*x4

---

Doit on réécrire ce code, ou bien le compilateur va-t-il faire quelque chose de très rapide ?

Le compilateur fera ce qu'il faudra.