Grosse différence de performance en changeant de compilateur (sous Mac OS X)

Bonjour à tous,

Je souhaiterais vous faire partager une expérience réalisée sous Mac OS X, qui me laisse totalement perplexe 8O
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 :weird:
(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 !

Salut,

Citation:

---

Envoyé par Alexoy82

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 ?

Citation:

---

Envoyé par Bousk

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 :)

Citation:

---

Envoyé par Alexoy82

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.

Citation:

---

Envoyé par Alexoy82

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

Citation:

---

Envoyé par Ehonn

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 :weird::weird::weird:
Dans les deux cas, la fonction sizeof() affiche 8 et 4 pour le double et le int 8O

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

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.

Citation:

---

Envoyé par Ehonn

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

Citation:

---

Envoyé par Iradrille

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:

---

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é :calim2::calim2::calim2:

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

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.

ç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:

---

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); }

---

As-tu essayé avec une lambda?

Citation:

---

Envoyé par dragonjoker59

As-tu essayé avec une lambda?

---

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

Un truc comme ça:

Code:

---

1 2 3 4

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

---

Ou un foncteur du genre si ta pas de lambdas.

Code:

---

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

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

Citation:

---

Envoyé par dragonjoker59

Un truc comme ça:

Code:

---

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 !

:) :) :)

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

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.

Citation:

---

Envoyé par JolyLoic

Ca n'empêche pas que je ne comprends pas trop pourquoi la syntaxe passant *this avec un operateur[] surchargé posait problème.

---

La copie des vecteurs engendrée par la prise par copie dans std::sort ? Voir des multiples copie si on regarde l'implémentation.
Amha, std::ref(*this) sera aussi efficace qu'une lambda.

Citation:

---

Envoyé par jo_link_noir

La copie des vecteurs engendrée par la prise par copie dans std::sort ? Voir des multiples copie si on regarde l'implémentation.
Amha, std::ref(*this) sera aussi efficace qu'une lambda.

---

En effet, c'est une possibilité très forte. Et j'imagine que ce qui a pu changer est qu'on passe d'une implémentation avec peu de copies à une implémentation qui copie beaucoup plus ? En tout cas, je serais curieux de savoir le résultat avec le std::ref(*this) pour confirmer l'hypothèse.

Citation:

---

Envoyé par Alexoy82

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.

---

Qu'est-ce qui te permet de dire ça ?
GCC 4.9 est compatible OpenMP 4.0 (voir https://gcc.gnu.org/wiki/openmp).

Quelles options de compilation et d'édition de lien liées à OpenMP utilises-tu ?