De la rapidité du code

Version imprimable

Voir 40 message(s) de cette discussion en une page

29/07/2007, 16h37
spidermario

Citation:

Envoyé par Médinoc

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...

Sauf si l'on prend en compte qu'avec certains compilateurs, une affectation est de type void.
29/07/2007, 18h16
Jean-Marc.Bourguet

Citation:

Envoyé par Miles

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

Tu as une référence?
29/07/2007, 18h16
Jean-Marc.Bourguet

Citation:

Envoyé par spidermario

Sauf si l'on prend en compte qu'avec certains compilateurs, une affectation est de type void.

Est-ce que ce sont des compilateurs C? Si oui, signale leur le bug.
29/07/2007, 19h27
spidermario

Je n'ai pas vu de compilateur dans ce cas, j'ai simplement lu qu'il y en avait :?

Peut-être que c'est faux, j'en sais rien :roll:
29/07/2007, 19h35
Jean-Marc.Bourguet

Citation:

Envoyé par spidermario

Je n'ai pas vu de compilateur dans ce cas, j'ai simplement lu qu'il y en avait :?

Où, qu'on déconseille cette source?
28/11/2007, 09h24
_vince_

de la rapidite de lecture du code

Citation:

Envoyé par jfloviou

Bonjour à tous, je suis nouveau sur ce forum et suis à la recherche de tous les trucs et astuces du plus bateau au plus compliqué pour un code plus efficace en vitesse de calcul: ex mieux vaut une boucle FOR ou l'usage du WHILE ? La pile est elle vraiment plus rapide que le tas?
l'usage de inline c'est mieux pour la vitesse?

et tous les autres...

Donc si vous connaissez des sites, ou des astuces, merci!

jaja

Bonjour,

Avant d'optimiser les performances d'execution, il faut d'abord penser a optimiser le code en lecture, i.e. ecrire du code lisible pour les humains.
On ne le repetera jamais assez, les programmes sont d'abord fait pour les humains et ensuite pour les machines.

Pense au programmeur qui reprend le code apres toi et qui passe des heures a comprendre pourquoi l'idiot precedent n'a pas voulu ecrire un code clair, tout ca pour gagner une instruction parmi des millions...
28/11/2007, 09h29
FloMo

Citation:

Envoyé par _vince_

Bonjour,

Avant d'optimiser les performances d'execution, il faut d'abord penser a optimiser le code en lecture, i.e. ecrire du code lisible pour les humains.
On ne le repetera jamais assez, les programmes sont d'abord fait pour les humains et ensuite pour les machines.

Pense au programmeur qui reprend le code apres toi et qui passe des heures a comprendre pourquoi l'idiot precedent n'a pas voulu ecrire un code clair, tout ca pour gagner une instruction parmi des millions...

Je confirme : un code clair est d'autant plus facile à optimiser que l'on sait immédiatement cibler l'endroit où il y a une perte éventuelle. De plus, si le code est simple, le compilateur saura mieux optimiser sa sortie.

accelerer le trie

Bonjour,
les trie de la STL utilise pas mal la fonction template std::swap. Il est donc préférable que les class, possedant des variable dynamique(tableau, string, vector ...) stockées dans un contenaire implémente un swap pour optimiser les trie. Cela permet de remplacer un swap constitué de 3 operation égale( donc trois recopie de mémoire) à un échange de memoire

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
#include <algorithm>
#include <iostream>
#include <vector>
#include <string>
 
//class qui contient la fonction swap pour éviter des recopie de memoire
class A
{
public :
	A(int a,std::string s) :myString(s),nb(a){ };
 
	const std::string &GetString() {return myString;}
	bool operator<(const A& a)const {return nb<a.nb;}
	A&  operator=(const A& a)
		{
		static int nbegale(0);
		std::cout<<"= : "<<++nbegale<<std::endl;
		nb=a.nb;
		myString=a.myString;
		return (*this);
		}
	void swap(A& a)
		{
			static int nbswap(0);
			std::cout<<"swap : "<<++nbswap<<std::endl;
			std::swap(nb,a.nb);
			myString.swap(a.myString);
		};
private:
        //varible qui "prend du temps" lors d'une recopie 
	std::string myString;
	int nb;
 
};
//specialisation de la fonction std::swap pour la class A
namespace std
{
template<>
inline void swap<A> ( A& a, A& b )
{
	a.swap(b);
};
}
 
int main(int argc, char** argv)
{
	//mon vecteur a trier
	std::vector<A> vect;
       //on remplie de n'importe quoi
      //le but etant quil y en ai assez pour que swap soit appelé
	vect.push_back(A(2,"deux"));
	vect.push_back(A(15,"quinze"));
	vect.push_back(A(10,"dix"));
	vect.push_back(A(5,"cinq"));
	vect.push_back(A(1,"un"));
	vect.push_back(A(30,"trente"));
	vect.push_back(A(2,"deux"));
	vect.push_back(A(15,"quinze"));
	vect.push_back(A(10,"dix"));
	vect.push_back(A(5,"cinq"));
	vect.push_back(A(1,"un"));
	vect.push_back(A(30,"trente"));
	vect.push_back(A(2,"deux"));
	vect.push_back(A(15,"quinze"));
	vect.push_back(A(10,"dix"));
	vect.push_back(A(5,"cinq"));
	vect.push_back(A(1,"un"));
	vect.push_back(A(30,"trente"));
	vect.push_back(A(2,"deux"));
	vect.push_back(A(15,"quinze"));
	vect.push_back(A(10,"dix"));
	vect.push_back(A(5,"cinq"));
	vect.push_back(A(1,"un"));
	vect.push_back(A(30,"trente"));
	vect.push_back(A(2,"deux"));
	vect.push_back(A(15,"quinze"));
	vect.push_back(A(10,"dix"));
	vect.push_back(A(5,"cinq"));
	vect.push_back(A(1,"un"));
	vect.push_back(A(30,"trente"));
	vect.push_back(A(2,"deux"));
	vect.push_back(A(15,"quinze"));
	vect.push_back(A(10,"dix"));
	vect.push_back(A(5,"cinq"));
	vect.push_back(A(1,"un"));
	vect.push_back(A(30,"trente"));
	vect.push_back(A(2,"deux"));
	vect.push_back(A(15,"quinze"));
	vect.push_back(A(10,"dix"));
	vect.push_back(A(5,"cinq"));
	vect.push_back(A(1,"un"));
	vect.push_back(A(30,"trente"));
	vect.push_back(A(2,"deux"));
	vect.push_back(A(15,"quinze"));
	vect.push_back(A(10,"dix"));
	vect.push_back(A(5,"cinq"));
	vect.push_back(A(1,"un"));
	vect.push_back(A(2,"deux"));
	vect.push_back(A(15,"quinze"));
	vect.push_back(A(10,"dix"));
	vect.push_back(A(5,"cinq"));
	vect.push_back(A(1,"un"));
	vect.push_back(A(30,"trente"));
	vect.push_back(A(2,"deux"));
	vect.push_back(A(15,"quinze"));
	vect.push_back(A(10,"dix"));
	vect.push_back(A(5,"cinq"));
	vect.push_back(A(1,"un"));
	vect.push_back(A(30,"trente"));
	vect.push_back(A(2,"deux"));
	vect.push_back(A(15,"quinze"));
	vect.push_back(A(10,"dix"));
	vect.push_back(A(5,"cinq"));
	vect.push_back(A(1,"un"));
	vect.push_back(A(2,"deux"));
	vect.push_back(A(15,"quinze"));
	vect.push_back(A(10,"dix"));
	vect.push_back(A(5,"cinq"));
	vect.push_back(A(1,"un"));
	vect.push_back(A(2,"deux"));
	vect.push_back(A(15,"quinze"));
	vect.push_back(A(10,"dix"));
	vect.push_back(A(5,"cinq"));
	vect.push_back(A(1,"un"));
	vect.push_back(A(2,"deux"));
	vect.push_back(A(15,"quinze"));
	vect.push_back(A(10,"dix"));
	vect.push_back(A(5,"cinq"));
	vect.push_back(A(1,"un"));
	vect.push_back(A(2,"deux"));
	vect.push_back(A(15,"quinze"));
	vect.push_back(A(10,"dix"));
	vect.push_back(A(5,"cinq"));
	vect.push_back(A(1,"un"));
	vect.push_back(A(30,"trente"));
	vect.push_back(A(30,"trente"));
	vect.push_back(A(30,"trente"));
	vect.push_back(A(30,"trente"));
	vect.push_back(A(30,"trente"));
	vect.push_back(A(30,"trente"));
 
     //on fait le trie
	std::sort(vect.begin(),vect.end());
	return 0;
}

En posant :
- duré d'un égale = 1s
- durée d'un swap = .5s (echange de la mémoire, donc peut de recopie)

Les résultats que j'obtiens sous visual 20005 sont :
- sans le swap : 234 operation egale = 234s
- avec le swap : 74 operation swap et 72 operation egale = 109 s

Les résultats que j'obtiens avec GCC sous ubuntu sont :
- sans le swap : 361 operation egale = 361s
- avec le swap : 88 operation swap et 185 operation egale = 229 s

voici un lien qui explique un peu :
http://www.tantalon.com/pete/cppopt/...l.htm#Swapping

08/06/2008, 15h47
zenux
J'ai une petite question, qu'est ce qui est le plus rapide :

code 1 :
Code:

1 2 for(int i=0;i<vec.size();i++) vec[i]->unBool = false;
code 2:
Code:

1 2 3 for(int i=0;i<vec.size();i++) if(vec[i]->unBool = true) vec[i]->unBool = false;
Je me doute bien que si "unBool" est 99% du temps à "true", le premier code sera plus rapide. Mais à partir de quel pourcentage le code numéro 2 sera plus rapide ?

Merci d'avance

Citation:
Envoyé par zenux
J'ai une petite question, qu'est ce qui est le plus rapide :

code 1 :
Code:

1 2 for(int i=0;i<vec.size();i++) vec[i]->unBool = false;
code 2:
Code:

1 2 3 for(int i=0;i<vec.size();i++) if(vec[i]->unBool = true) vec[i]->unBool = false;
Je me doute bien que si "unBool" est 99% du temps à "true", le premier code sera plus rapide. Mais à partir de quel pourcentage le code numéro 2 sera plus rapide ?

Merci d'avance
Déjà, fais attention au test que tu excécute...

En effet, si tu fais un test du genre de

Code:

if(test[i]->unBool = true)

tu commence par assigner true à test[i]->unBool... et donc, le test sera toujours vrai...

Pour que ce soit réellement un test, ce serait

Code:

if(test[i]->unBool == true)

En outre, il serait peut-être préférable de déclarer i comme étant un size_t, ce qui est le type renvoyé par size ;)

Ceci dit, il faut savoir que, si tu fais un test de manière inopportune, ce sera toujours plus lent que si tu ne le fais pas.

Il n'y a rien à faire, un test demande un certain nombre de cycle d'horloge processeur, et donc, fatalement, cela "ralenti" un peu le code :P

Pour qu'il présente un avantage, il faudrait que les instructions à effectuer dans le cas où le test est vérifié soient plus nombreuses, de manière, justement, à éviter d'effectuer le nombre d'exécutions quand elles ne sont pas nécessaire.

Ainsi, il devient opportun de placer le test si ton code doit se présenter sous une forme proche de
Code:

1 2 3 4 5 6 7 8 9 10 for(size_t i=0;i<test.size();++i) { if(test[i]->unBool == true) { /* une série d'instructions potentiellement "longue" à l'exécution * mais, en tout cas, plus importante que la simple assignation * d'un type primitif */ } }

11/06/2008, 14h46
loufoque

La version avec le if sera probablement plus longue, parce que les branchements empêchent la prédiction d'instruction de fonctionner (ainsi que la vectorisation automatique).
18/08/2008, 05h07
deadalnix

Ma petit pierre a l'édifice :

Pour ceux qui trouvent que gcc est long a compiler (ce qui est vrai tout de même), il est important de savoir que par defaut, il le fait sur un seul thread. En utilisant l'option j, on peut augmenter le nombre de thread et profiter a fond de notre beau dual/quad core ;)
18/08/2008, 12h29
screetch

c'est pas plutot make qui a cette option ? et scons ?
18/08/2008, 14h53
Alp

GCC aussi la possède.
18/08/2008, 14h56
Jean-Marc.Bourguet

Citation:

Envoyé par Alp

GCC aussi la possède.

C'est moi qui suis distrait ou je ne la vois pas ici:
http://gcc.gnu.org/onlinedocs/gcc-4....n-Summary.html
18/08/2008, 15h09
Alp

Ou alors c'est moi qui ai fumé quelque chose de nocif pour la mémoire. Toutes mes excuses :)
18/08/2008, 15h36
screetch
de toute facon la compilation est quelque chose de sequentiel, pas vraiment beaucoup de place pour le multi core. En revanche, make a une vue d'ensemble qui permet de decouper les taches en sequences indépendantes.

La ou GCC est lent, c'est que c'est souvent utilisé en simple fichier :
Code:

1 2 3 4 5 gcc -c file1.cpp -o file1.obj gcc -c file2.cpp -o file2.obj gcc -c file3.cpp -o file3.obj gcc -c file4.cpp -o file4.obj gcc -c file5.cpp -o file5.obj
alors que sous visual, en general c'est une seule instance du compilo qui fait tous les fichiers. en utilisant gcc de la meme facon, il est sensiblement plus rapide.
17/05/2009, 03h21
Alp

Depuis les derniers messages, on en sait plus sur C++0x, on a des nouvelles versions de compilos, etc.

Vous avez d'autres conseils pour ceux qui voudraient accélérer leur code ?

Par ailleurs, êtes-vous tous d'accord pour dire que C++ va rester parmi les plus rapides, devant Java et les langages .NET par exemple ? Malgré leur VM, ils obtiennent parfois de bonnes performances, mais a priori rien ne va ralentir le C++. Il est toutefois à la charge des programmeurs C++ de connaître les trucs & astuces pour avoir un code performant et bien pensé :)
17/05/2009, 09h41
Matthieu Brucher

Citation:

Envoyé par Alp

Depuis les derniers messages, on en sait plus sur C++0x, on a des nouvelles versions de compilos, etc.

Vous avez d'autres conseils pour ceux qui voudraient accélérer leur code ?

Par ailleurs, êtes-vous tous d'accord pour dire que C++ va rester parmi les plus rapides, devant Java et les langages .NET par exemple ? Malgré leur VM, ils obtiennent parfois de bonnes performances, mais a priori rien ne va ralentir le C++. Il est toutefois à la charge des programmeurs C++ de connaître les trucs & astuces pour avoir un code performant et bien pensé :)

Mais il manque furieusement un mot-clé "restrict" comme en C99 pour avoir les performances en calcul de Fortran...
17/05/2009, 11h22
Invité

Citation:

Envoyé par Alp

Par ailleurs, êtes-vous tous d'accord pour dire que C++ va rester parmi les plus rapides, devant Java et les langages .NET par exemple ? Malgré leur VM, ils obtiennent parfois de bonnes performances, mais a priori rien ne va ralentir le C++. Il est toutefois à la charge des programmeurs C++ de connaître les trucs & astuces pour avoir un code performant et bien pensé :)

C'est le vieux débat entre langages compilés et interprétés... Au fur et à mesure que la puissance de calcul augmente, les interpréteurs vont plus vite, mais les processeurs aussi quand ils exécutent un code compilé. C'est pareil pour les progrès théoriques : meilleurs interpréteurs, meilleurs compilateurs.

En ce sens, C++ conservera sa longueur d'avance. Ma seule réserve est la tendance au développement des librairies annexes. Ce n'est pas un mal en soi, mais cela transforme parfois le C++, à l'origine rapide parce que compilé et "proche de la machine" (une instruction C++=peu d'instructions machine), en un autre langage de haut niveau. Il appartient aux programmeurs C++ de savoir quand *ne pas* utiliser telle ou telle librairie ultrapuissante, dont ils n'ont pas besoin...

Mes petits conseils d'optimisation

1- ne pas trop s'inquiéter des multiplications, des floats et des doubles, des pré et post incrémentations sur types de base, le compilateur fait ça mieux que nous (et ce n'est pas du tout intuitif)...
2- se méfier comme de la peste des "bonnes idées" d'optimisation quand on fait des calculs numériques, une simplification mal à propos donne souvent des calculs très très faux. Les algorithmes mathématiques, les prendre dans des livres et des librairies spécialisées, plutôt que dans ses souvenirs de terminale (ou de prépa).
3- évaluer la volumétrie de ses programmes avant de les écrire : il ne sert à rien d'utiliser des moyens importants pour gérer efficacement une structure que comprend très peu d'objets, en revanche, savoir à l'avance qu'un petit tableau à l'air innocent contiendra probablement 1 000 000 d'objets, et pas 1000 comme on se disait au début, permet de partir sur de bonnes bases
4- quand on travaille sur de grosses données externes, se poser dès le début la question de l'ordre dans lequel on va les utiliser. Trier ses données dans le bon ordre, avant l'exécution, permet souvent de gagner sur plusieurs tableaux (mémoire et vitesse)
5- utiliser un profileur, tout le temps, presque dès le début, pas pour optimiser, mais pour savoir où le temps est passé. Généralement savoir où est le problème c'est presque le résoudre
6- résister aux sirènes des bibliothèques ultra avancées : si j'ai une date à gérer, dans un très gros tableau, il n'est pas certain que la bibliothèque dates de la mort qui tue (même du standard) me serve, peut être que juste prétendre que c'est un entier...
7- quand on optimise (à la fin) procéder en deux temps. D'abord, avec un profileur, rechercher les "erreurs bêtes", les quelques instructions ou fonctions qui perdent un temps fou et qu'on peut remplacer (généralement, des fonctions haut niveau mal à propos). Ensuite, et si nécessaire, regarder les parties du programme où le temps est passé, et y réfléchir en termes d'algorithmes ou de données...

Francois

Voir 40 message(s) de cette discussion en une page