Optimisation -> inline et constructeurs

**oldfox** · 26/01/2006, 17h31

Bonjour, je suis en train de coder une petite librairie mathématique, et j'ai quelques problemes étranges...

J'ai commencé à coder une classe matrice3x3, entierement écrite dans le .h (beurk

), avec des mots clés inline notamment sur les surcharges d'opérateurs (meme si je suppose que les fonctions déclarées en plein .h sont passées automatiquement inline par le compilo, surtout ke je demande rapidité au détriment de la taille de l'ecécutable)

Bref tout va bien, sur une boucle j'effectue 5 milliards de produits matriciels en 5 secondes Ca me parait tres tres rapide, j'espere ne pas etre trompé par une optimisation quelconque sachant ke je multiplie toujours les deux meme matrices...

Le probleme vient quand j'écrit un .cpp et que j'y place les constructeurs de la classe... Les performances sont en chute libre! Par un facteur surement de plus de 10.

Est-ce que cela vient du fait k'il n'ya plus de inline possible lorsque je place du code dans le .cpp?
Comment retrouver les performances du début en pouvant écrire le code proprement dans un .cpp?

Merci a vous...

edit : 5 secondes en fait

**fearyourself** · 26/01/2006, 17h59

Bref tout va bien, sur une boucle j'effectue 5 milliards de produits matriciels en 5 secondes Ca me parait tres tres rapide, j'espere ne pas etre trompé par une optimisation quelconque sachant ke je multiplie toujours les deux meme matrices...

Lance 1 milliards de produits et regarde si cela prend une seconde...

Jc

**oldfox** · 26/01/2006, 18h04

Oui oui c'est le cas

Je voulais surtout dire que je ne sais pas si ya pas des bidouilles pour éviter de recalculer ce qui vient de l'être par exemple (mécanisme de cache). M'enfin bon si c'est rapide a ce point tant mieux je suis content de pouvoir faire bruler le fortran lol

**Laurent Gomila** · 26/01/2006, 18h25

Je voulais surtout dire que je ne sais pas si ya pas des bidouilles pour éviter de recalculer ce qui vient de l'être par exemple (mécanisme de cache)

Effectivement moi si j'étais toi je ferais attention à ce genre de choses.

Sinon pour les fonctions inline, même combat que pour les templates : si le compilo ne peut accéder à la définition de la fonction inline (ie. si elle est cloîtrée dans un .cpp), il ne pourra jamais l'inliner...

**oldfox** · 26/01/2006, 18h29

Ok, donc la réponse c'est : je dois faire des .h de goret si je veux que ca fonce?

**Laurent Gomila** · 26/01/2006, 18h32

Envoyé par oldfox

Ok, donc la réponse c'est : je dois faire des .h de goret si je veux que ca fonce?

Tu peux tout de même séparer les fichiers (mais pas de .cpp), même si pour le compilo ça reviendra au même. Ce sera un peu plus propre.

**oldfox** · 26/01/2006, 18h40

Deux .h dont l'un inclu l'autre?

Ca va être beau tout ca

Merci

**Laurent Gomila** · 26/01/2006, 21h06

Envoyé par oldfox

Deux .h dont l'un inclu l'autre?

Plutôt un .h et un .inl (ou n'importe quoi d'autre). Ca fera toujours un peu plus classe, et ça explicitera un peu plus le rôle du fichier.

**xxiemeciel** · 27/01/2006, 03h18

Salut,

Une petite precision sur ton test de 5 milliards d'iterations. J'ai fait beacoup de tests de performances de se genre a mon travail et je me suis rendu compte que le compilateur ignorait tout simplement la boucle si le resultat calculé a l'interieur n'est pas utilisé et ne modifie rien

par exemple dans le cas suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
void maFonctionTest()
{
     double sum = 1.0;
     for(int i=0; i < 1 000 000 000; i++)
    {
          sum+=1.0;
     }
}

l'execution sera tres rapide puisque la valeur de sum n'est pas utilisé et l'interieur de la boucle ne change rien a ton environnement donc le compilateur l'ignore.

Par contre le cas suivant va etre tres different :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
void maFonctionTest()
{
     double sum = 1.0;
     for(int i=0; i < 1 000 000 000; i++)
    {
          sum+=1.0;
     }
    std::cout << sum << "\n";
}

puisque le resultat de la boucle est utilisé.

Maintenant moi j'utilise le compilo de visual studio (le payant) qui optimise beaucoup donc c'est peut etre pas le cas pour d'autre compilateur.

XXiemeciel

**oldfox** · 27/01/2006, 07h27

Je suis aussi sur visual. Faudra que j'essaye avec des nombres aléatoires peut etre dans les matrices... Mais le fait que le temps augmente linéairement me fait pense que c'est bon, que c'est juste le c++ qui avale les matrices tres tres vite

La il n'ya pas d'utilisation du résultat mais je mettais le cout<< avant et ca avait des perf similaires.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
QueryPerformanceCounter(&tic);
	for (long long int i = 0; i<5000000000; ++i){
		m3=m1*m2;
	}
	QueryPerformanceCounter(&tac);
	double time = 1000.0 * (tac.QuadPart - tic.QuadPart) / Frequency.QuadPart;
	cout << i << " multiplications matricielles 3x3 ";
	cout << " temps ecoule : " << time << "ms " << endl<<endl<<endl;

J'ai dailleurs perdu pres de deux secondes de traitement depuis que j'ai rajouté d'autres classes dans le programme

Vous voyez de quoi ca peut venir? C'est inévitable? Mon exe ne passe pourtant que de 92ko a 100ko entre la version qui met 5s et la version qui met 7 ....

**JolyLoic** · 27/01/2006, 08h26

Visual C++ possède (à partir de la version 7.1 je crois), une option "whole program optimisation". Je t'invite à regarder de ce côté.

http://msdn2.microsoft.com/en-us/library/0zza0de8.aspx

**Matthieu Brucher** · 27/01/2006, 10h11

Envoyé par JolyLoic

Visual C++ possède (à partir de la version 7.1 je crois), une option "whole program optimisation". Je t'invite à regarder de ce côté.

http://msdn2.microsoft.com/en-us/library/0zza0de8.aspx

Je croyais que c'était .NET 2005 en version non express ??

Sinon, ta fonction est optimisée à fond, le compilo ne fait sans doute qu'une seule fois l'opération. Il est IMPOSSIBLE de fare autant de multiplications en si peu de temps.

**oldfox** · 27/01/2006, 12h19

J'utilise deja toutes les options d'optimisation disponibles. La "global optimization" ne change rien a la perte de perf quand j'ajoute deux autres classes malheureusement.

Pour le temps, je vais essayer de changer la methode de chronometrage pour etre sur. Car c'est vrai que 5 milliards de produits matriciels, ca fait un sacré paquet de multiplications

edit: Bon j'avais bien une optimisation qui trainait comme je le craignais

Mais 100 millions de produits matriciels en 5 secondes ca reste honorable

C'est pour de la modelisation physique donc plus je peux en faire a la seconde mieux je me porte...

De plus le probleme de baisse de perf avec plus de classe semble avoir disparu

Ca devait venir de cette optimisation...

Bon ba impécable plus qu'a rendre les .h lisibles et a continuer de bosser

**xxiemeciel** · 27/01/2006, 14h15

Salut,

Les processeurs AMD et Pentium 4 posseedent aussi une optimisation a la compilation SSE et SSE2 qui optimise les calculations mathematique en nombres flottants.

les performances peuvent augmenter jusqu'a 15% dans certains cas.

XXiemeciel

**oldfox** · 27/01/2006, 15h53

J'imagine que c'est géré silencieusement par VS7.1 ca non? Car je ne vois aucune option explicite la dessus si ce n'est "optimize for processor : blended / PIV or above".

**xxiemeciel** · 27/01/2006, 16h23

Envoyé par oldfox

J'imagine que c'est géré silencieusement par VS7.1 ca non? Car je ne vois aucune option explicite la dessus si ce n'est "optimize for processor : blended / PIV or above".

si tu parles ici de l'option SSE ou SSE2 ce n'est pas par default tu dois le demander pour l'avoir. Et generalement il faut le mettre dans la ligne de command du compilateur (tu trouveras toutes les options sur le site MSDN)

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/vclrfArchMinimumCPUArchitecture.asp

mais attention cette option empeche le fonctionnement du programme sur des processeurs ne gerant pas SSE / SSE2.

XXiemeciel

Optimisation -> inline et constructeurs

C++

Discussions similaires

Partager

Partager