Discussion :

[Alexoy82]

Bonjour à tous,

Je souhaiterais vous faire partager une expérience réalisée sous Mac OS X, qui me laisse totalement perplexe
La version de g++ fournie par Apple avec Xcode est la 4.9.2 (20141029 prerelease).
Ce compilateur fonctionne très bien, mais n'est pas compatible avec OpenMP.
J'ai donc choisi de télécharger la version g++-5.1.0 et de la compiler sur ma machine (en suivant ce tutoriel).

Mon projet compile parfaitement avec g++-5.1.0, mais l'exécution est beaucoup plus lente qu'avec le compilateur par défaut
(un traitement qui prenait 9 secondes, prend maintenant 1 minute et demi)
J'ai également fait le test en utilisant seulement l'algo de trie std::sort() et le phénomène est le même !

Finalement, OpenMP fonctionne bien avec g++-5.1.0 mais les temps d'exécution sont beaucoup trop long

Donc voici ma question : Pensez-vous qu'Apple optimise le compilateur fourni avec Xcode ?
Si vous avez des pistes pour expliquer cette différence, je suis preneur merci !

[Bousk]

Salut,

Donc voici ma question : Pensez-vous qu'Apple optimise le compilateur fourni avec Xcode ?

Ca m'étonnerait.

Es-tu absolument sûr d'utiliser les mêmes options ?
Est-ce que c'est pas ton code qui utilise OpenMP qui est juste plus lent ?
Comment peux-tu comparer si la précédente version ne compilait pas avec OpenMP ?

[Alexoy82]

Salut,

Ca m'étonnerait.

Es-tu absolument sûr d'utiliser les mêmes options ?
Est-ce que c'est pas ton code qui utilise OpenMP qui est juste plus lent ?
Comment peux-tu comparer si la précédente version ne compilait pas avec OpenMP ?

Voici les options de compilation que j'utilise dans les deux cas : -O2 -Wall -c -fmessage-length=0 -std=c++11
Et je retire tout ce qui concerne OpenMP pour faire ma comparaison ... le même code est exécuté et pourtant g++-5.1.0 est beaucoup plus lent

J'ai peut être trouvé une piste : l'espace occupé en RAM par mon programme n'est pas le même selon le compilateur :

17 Mo avec g++-5.1.0
11 Mo avec g++ par défaut (4.9.2)

Mon programme sollicite beaucoup la RAM (lecture/écriture) ... donc la différence du temps d'exécution pourrait s'expliquer ?

Voici ma deuxième question : Est-il possible qu'un "double" ou qu'un "int" occupe plus de place en mémoire avec g++-5.1.0 qu'avec la version 4.9.2 ?
J'imagine que les types standards n'occupent pas le même nombre de bits si le programme est compilé en 32 bits ou en 64 bits ?

Merci de votre aide

[Ehonn]

Mon programme sollicite beaucoup la RAM (lecture/écriture) ... donc la différence du temps d'exécution pourrait s'expliquer ?

Oui, accéder à la mémoire reste une opération lente.

Voici ma deuxième question : Est-il possible qu'un "double" ou qu'un "int" occupe plus de place en mémoire avec g++-5.1.0 qu'avec la version 4.9.2 ?
J'imagine que les types standards n'occupent pas le même nombre de bits si le programme est compilé en 32 bits ou en 64 bits ?

Affiche les tailles avec sizeof(int) et sizeof(double).

[Alexoy82]

Oui, accéder à la mémoire reste une opération lente.


Affiche les tailles avec sizeof(int) et sizeof(double).

Merci pour ta suggestion
mais cela n'a pas l'air d'être la source de mon problème
Dans les deux cas, la fonction sizeof() affiche 8 et 4 pour le double et le int

[dragonjoker59]

Salut!

Vérifie les options de compilation de GCC pour les 2 versions, avec gcc -vDe plus as-tu effectué la compilation de GCC par lui-même? Si je me souviens bien, il faut en tout compiler GCC 3 fois

[white_tentacle]

Pour la compilation, la fais-tu en ligne de commande ou depuis ton environnement ?

--> il est possible que l’environnement te rajoute des options. Je pense typiquement à un problème de compilation en debug au lieu de release, qui est l’explication la plus logique à la grosse différence de perf.

[Iradrille]

Oui, accéder à la mémoire reste une opération lente.

Accéder à la mémoire c'est lent, mais le programme est le même donc c'est lent dans les 2 cas.

Une différence de ~10/20% entre 2 versions de compilos parait normale (et encore, ça commence à faire beaucoup).

Mais ici je pense plus à des options de compilation différentes (typiquement : debug vs release).

[Alexoy82]

Accéder à la mémoire c'est lent, mais le programme est le même donc c'est lent dans les 2 cas.

Une différence de ~10/20% entre 2 versions de compilos parait normale (et encore, ça commence à faire beaucoup).

Mais ici je pense plus à des options de compilation différentes (typiquement : debug vs release).

J'ai fait une compilation en ligne de commande en suivant ce tutoriel (ici). J'ai d'abord compilé les librairies 'mec', 'mpfr', 'gmp'. Puis pour finir, j'ai compilé g++-5.1.0 de la façon suivante

Code :

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

1
2
3
4
5
../configure --prefix=/usr/gcc-5.1.0 --enable-checking=release --with-gmp=/usr/gcc-5.1.0 --with-mpfr=/usr/gcc-5.1.0 --with-mpc=/usr/gcc-5.1.0 --enable-languages=c,c++,fortran --with-isl=/usr/gcc-5.1.0 --program-suffix=-5.1.0
 
make -j 4
 
sudo make install

Pourriez-vous me dire quelle sont les options qui caractérisent le mode 'release' ?
J'ai essayé -O2 et -s (je ne connais l'option -v mais je l'ai essayé)

Mais rien ne change ... je suis désespéré

[dragonjoker59]

../configure --help ?
Je pense à une option du genre --build-type=release ou --build=release

[white_tentacle]

La manière dont tu compiles gcc ne changera pas grand chose au temps d’exécution de tes programmes (éventuellement, ça changera sur leur temps de compilation).

C’est bien les options que tu utilises pour compiler ton programme qui vont avoir une énorme influence sur son temps d’exécution.

[Alexoy82]

ça y est ! Je viens de cerner le problème .... qui se trouve dans le code
Mon programme est extrêment lent lorsque std::sort() est utilisée pour faire un trie personalisé.

Par exemple dans la classe "typePredictionsProba" j'ai un vecteur de double dont je souhaite conserver l'ordre.
Pour fixer les idées, disons que ce vecteur "predictedProba" = [0.8, 0.5, 0.1] et l'ordre des éléments ne doit pas changer.
A coté, un autre vecteur d'entiers est initalisé avec des valeurs croissantes, "sortedIndex" = [0,1,2].
Ce deuxième vecteur doit être trié et indique les indexes des éléments de "predictedProba" dans l'ordre croissant.
Après le trie, "sortedIndex" = [2,1,0], car le plus petit élément de "predictedProba" est à la position 2 et le plus grand à la position 0.

Le code suivant montre comment la fonction de trie est appellée :

std::sort(sortedIndex.begin(),sortedIndex.end(),*this)

Visiblement, g++-5.1.0 n'apprécie pas le *this comme 3ème argument de la fonction sort().
Une utilisation plus standard de sort() implique de mettre l'opperateur() dans une structure dédiée.
Mais je ne pense pas pouvoir faire cela dans mon cas

A titre de test, si j'effectue un trie standard : std::sort(sortedIndex.begin(),sortedIndex.end()) en retirant le *this,
je retrouve exactement le même temps de calcul qu'avec g++ 4.9.2.

C'est dingue !

Avez-vous une explication pour cette différence de comportement entre les deux compilateurs ?
Et avez-vous des idées pour modifier l'appel à la fonction sort() afin d'éviter le problème ?

Merci

Code :

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

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
class typePredictionsProba {
 
private:
	vector<double> predictedProba;							
	vector<int> sortedIndex;						
 
public:
 
	typePredictionsProba();
	virtual ~typePredictionsProba();
 
	bool operator() (int i,int j);						
	void sort();										
};
 
 
/////////////////////////////////////////
// comparateur pour le trie des index
/////////////////////////////////////////
 
bool typePredictionsProba::operator() (int i,int j)
{
	return predictedProba[i]>predictedProba[j];
}
 
/////////////////////////////////////////////////
// trie des indexs
/////////////////////////////////////////////////
 
void typePredictionsProba::sort()
{
	std::sort(sortedIndex.begin(),sortedIndex.end(),*this);
}

[dragonjoker59]

As-tu essayé avec une lambda?

[Alexoy82]

As-tu essayé avec une lambda?

OUps ! c'est quoi une lambda ?
Désolé pour la question bête

[dragonjoker59]

Un truc comme ça:

Code :

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

1
2
3
4
std::sort(sortedIndex.begin(),sortedIndex.end(),[this]( int i, int j )
{
    return predictedProba[i] > predictedProba[j];
} );

[Iradrille]

Ou un foncteur du genre si ta pas de lambdas.

Code :

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

1
2
3
4
5
6
7
8
9
void typePredictionsProba::sort()
{
	struct foo {
		foo(typePredictionsProba& t): this_(t) { }
		bool operator()(int i, int j) { return t(i,j); }
		typePredictionsProba& this_;
	};
	std::sort(sortedIndex.begin(),sortedIndex.end(), foo(this));
}

std::sort doit générer un paquet de copies du comparateur (et donc des std::vector qu'il contient).

[jo_link_noir]

S'il n'y a pas de lambda, c++11 n'est pas active et mettre la structure dans la fonction ne fonctionnera pas non plus. Obligé de la définir dans le scope extérieur (la classe).

[Alexoy82]

Un truc comme ça:

Code :

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

1
2
3
4
std::sort(sortedIndex.begin(),sortedIndex.end(),[this]( int i, int j )
{
    return predictedProba[i] > predictedProba[j];
} );

Super ! ça marche

Merci beaucoup pour ton conseil !! je n'aurais jamais trouvé cela tout seul !

[dragonjoker59]

Tu devrais te renseigner sur le C++11 et C++14, vu le compilateur que tu utilises.

[JolyLoic]

Ca n'empêche pas que je ne comprends pas trop pourquoi la syntaxe passant *this avec un operateur[] surchargé posait problème. Je serais curieux de savoir ce que donne ce code avec d'autres compilateurs, histoire de voir s'il n'y a pas une explication, et éventuellement, je pense qu'un bug report à l'équipe de gcc serait de mise.