[Optimisation] Choix du compilateur

Citation:

---

mais a ce que je vois le code de demo est résumé par : [...]

---

Non le code de la fonction demo est :

Code:

---

1 2 3 4 5 6 7 8

0040103C xor eax,eax 0040103E cmp dword ptr [esp+4],0Ah ... 00401048 setge al 0040104B dec eax 0040104C and eax,0FFFFFFCFh 0040104F add eax,32h

---

Tout ce qu'il y a entre ces lignes et après ces lignes ne font pas "parti" de la fonction demo.
D'ailleur on voit que la fonction a été inliné. Peut-être à tu utilisés /GL ?

Citation:

---

Les gens qui se plaignent de GCC sont généralement des gens qui utilisent des versions obsolètes avec les mauvaises options.

---

Faux, suffit de comparer le code asm pour voir que GCC est à la traine. Seul "avantage" de GCC c'est qu'il supporte les dernières normes.
C99 pour le C tantdis que MSC++ reste à C90. ICL lui permet de choisir soit C90 soit C99.

Citation:

---

Envoyé par Charlemagne

Non, car j'ai toujours essayé également avec des versions antérieures de GCC et ICL. Rien à faire, GCC est lent par rapport à ICL.
Et toi, tu as quelle version d'ICL, si on peut savoir?

---

J'avoue n'avoir jamais essayé d'autre compilateur que GCC (si ce n'est celui de Borland, mais j'ai peu de souvenirs). Je souhaite juste que les tests soient faits correctement, quitte à déclarer que GCC soit moins performant !

Je compile le code suivant (au passage, on vire le __fastcall qui n'a rien de standard) avec GCC 4.3.1 sous Linux :

Code:

---

1 2 3 4 5 6 7 8 9 10

int demo(int n) { return n < 10 ? 1 : 50; }   int main(int argc, char** argv) { demo(argc); return 0; }

---

Avec les options -O3 et -march=pentium4 (options similaires au test de la page 1, donc), j'obtiens le code assembleur suivant :

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

.file "test.cpp" .text .globl _Z4demoi .type _Z4demoi, @function _Z4demoi: .LFB2: pushl %ebp .LCFI0: movl %esp, %ebp .LCFI1: movl $50, %eax cmpl $9, 8(%ebp) movl $1, %edx cmovle %edx, %eax popl %ebp ret .LFE2: .size _Z4demoi, .-_Z4demoi .globl main .type main, @function main: .LFB3: leal 4(%esp), %ecx .LCFI2: andl $-16, %esp pushl -4(%ecx) .LCFI3: pushl %ebp .LCFI4: movl %esp, %ebp .LCFI5: pushl %ecx .LCFI6: xorl %eax, %eax popl %ecx popl %ebp leal -4(%ecx), %esp ret .LFE3: .size main, .-main .ident "GCC: (Debian 4.3.1-8) 4.3.1" .section .note.GNU-stack,"",@progbits

---

Si je ne m'abuse, le code de la fonction demo est celui-ci :

Code:

---

1 2 3 4 5 6 7 8 9

.LCFI0: movl %esp, %ebp .LCFI1: movl $50, %eax cmpl $9, 8(%ebp) movl $1, %edx cmovle %edx, %eax popl %ebp ret

---

Voilà. On atteint certes pas le niveau d'ICL, mais face à VC++, je ne vois pas beaucoup de différences.
Je ne sais pas ce que ça donne en nombre de cycles machine, mais en ce qui concerne le nombre d'instructions, c'est kif kif bourricot.


Mais bon, une fonction avec un if, on a trouvé mieux comme banc de test pour compilateurs C++.

Déjà si ton compilo génère en -O3 :

Code:

---

1 2 3 4 5

push ebp mov ebp, esp ... pop ebp

---

Hum... hum...

MSC++ génère :

Code:

---

1 2 3 4 5 6 7 8

xor eax, eax cmp DWORD PTR _n$[esp-4], 10 ; 0000000aH setge al dec eax and eax, -49 ; ffffffcfH add eax, 50 ret

---

Faudrai que je vérifie mais même si MSC++ n'a pas générer l'instruction "conditional mov" ce code est plus rapide me semble t-il. Du fait que les push et les pop ont disparus.

Bien sûr le code généré par ICL :

Code:

---

1 2 3 4 5 6 7

mov edx, dword ptr[esp+4] mov ecx, 1 mov eax, 50 cmp edx, 10 cmovl eax, ecx ret

---

est optimal.

Citation:

---

Mais bon, une fonction avec un if, on a trouvé mieux comme banc de test pour compilateurs C++.

---

Si déjà on a des écarts de perf sur ça je te laisse imaginé ce que ça peut donné avec du code "complexe".

Hem, bon… y'aurait pas un mec qui s'y connaît en assembleur pour m'aider à argumenter ? :lol:

Je n'ai aucune idée de l'ampleur du travail que ça représente, mais c'est tout de même curieux que GCC ne fasse pas ces optimisations, si elles sont si basiques que ça, non ?

Citation:

---

Si déjà on a des écarts de perf sur ça je te laisse imaginé ce que ça peut donné avec du code "complexe".

---

Certainement, mais je demande tout de même à voir. Cela dépend de comment travaille le compilateur dans sa phase d'optimisation.

Par ailleurs, puisque tu sembles savoir de quoi tu parles, pourquoi ne pas signaler ce manquement sur le bugzilla de GCC ?
http://gcc.gnu.org/bugzilla/
Comme c'est un logiciel libre, c'est un peu notre compilateur à tous. Même si tu ne l'utilises pas, faire jouer la concurrence est toujours bon pour les consommateurs et utilisateurs que nous sommes ;).

Citation:

---

Envoyé par three minute hero

Hem, bon… y'aurait pas un mec qui s'y connaît en assembleur pour m'aider à argumenter ? :lol:

Je n'ai aucune idée de l'ampleur du travail que ça représente, mais c'est tout de même curieux que GCC ne fasse pas ces optimisations, si elles sont si basiques que ça, non ?


Certainement, mais je demande tout de même à voir. Cela dépend de comment travaille le compilateur dans sa phase d'optimisation.

---

Essaye de compiler avec l'option fastcall comme dans l'original.
Sous GCC ca devrait se dire "int __attribute__((fastcall)) demo(int n)".
Note: Je n'ai que cygwin et un vieux compilo sous la main.

- W

Voilà voilà :

Code:

---

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

_Z4demoi: .LFB2: pushl %ebp .LCFI0: movl %esp, %ebp .LCFI1: movl $50, %eax cmpl $10, %ecx movl $1, %edx cmovl %edx, %eax popl %ebp ret

---

Pas bien spectaculaire comme changement.

Normal.
%esp est un registre réservé pour la pile. GCC ne se permet pas de l'utiliser par défaut.
Avec -O3 -march=native -fomit-frame-pointer, moi j'obtiens

Code:

---

1 2 3 4 5 6

demo: cmpl $9, 4(%esp) movl $50, %edx movl $1, %eax cmovg %edx, %eax ret

---

J'obtiens ceci avec g++ -O3 -march=pentium4 -masm=intel -fomit-frame-pointer :

Code:

---

1 2 3 4 5 6 7

_Z4demoi: .LFB2: mov eax, 50 cmp ecx, 10 mov edx, 1 cmovl eax, edx ret

---

Merci loufoque, voilà qui est rassurant ;).

Citation:

---

Envoyé par three minute hero

Voilà voilà :

Code:

---

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

_Z4demoi: .LFB2: pushl %ebp .LCFI0: movl %esp, %ebp .LCFI1: movl $50, %eax cmpl $10, %ecx movl $1, %edx cmovl %edx, %eax popl %ebp ret

---

Pas bien spectaculaire comme changement.

---

Yup.
Je regarderais plus tard dans la soirée.
- W

J'ai testé ICC 10 et GCC 4.1, et en fait ICC ne fait pas beaucoup mieux, le gain est négligeable pour l'application que j'avais. Et c'est assez costaud tout de même ;)

Visual est aussi capable de générer du code pour un processeur spécifique, tout comme ICC est capable de générer un code pour toutes les plateformes. Le seul moyen de savoir quel est le meilleur compilateur dans ton cas, c'est de tester.

Et une autre méthode pour gagner du temps, c'est changer l'algorithme...

Citation:

---

Merci loufoque, voilà qui est rassurant [...]

---

Oui effectivement :P

Citation:

---

Visual est aussi capable de générer du code pour un processeur spécifique

---

Non pas depuis la version 2005.

Citation:

---

J'ai testé ICC 10 et GCC 4.1, et en fait ICC ne fait pas beaucoup mieux, le gain est négligeable pour l'application que j'avais.

---

ça dépend.
Si tu fais un programme "scientifique" comme résoudre des systèmes linéaires, rechercher le zéro des équations polynomiales, interpolation ect... et que tu compiles avec les optimisations + utilisation des instructions SSE le compilo Intel écrase MSC++ après je ne me prononcerai pas de manière certaine mais je pense que GCC serai aussi écrasé. Suffirai de comparer le code ASM généré mais en tout les cas ça me semble évident comme la pub Renault.

Citation:

---

Qui mieux que Renault pour entretenir votre Renault?

---

Citation:

---

Qui mieux qu'Intel pour générer un code performant sur les puces Intel?

---

:aie:
Je comparerai quand j'aurai un peu de temps le code généré par Mingw (puisque je tourne sous Windows), MSC++ et Intel avec un programme scientifique.

Sinon pour ceux qui veulent se lancé ou comprendre l'ASM un bon niveau d'anglais et un peu de temps libre pour lire :
Intel® 64 and IA-32 Architectures Software Developer's Manual
Volume 1: Basic Architecture
Intel® 64 and IA-32 Architectures Software Developer's Manual
Volume 2A: Instruction Set Reference, A-M
Intel® 64 and IA-32 Architectures Software Developer's Manual
Volume 2B: Instruction Set Reference, N-Z
Intel® 64 and IA-32 Architectures Optimization Reference Manual

sur le site web Intel

Il faut effectivement utiliser les intrinsics, mais si on ne les utilise pas, ça ne change rien. ICC n'ajoute pas de code SSE, même si c'est compilé pour la bonne plateforme, dans la majorité des cas. Et j'ai vérifié sur du code bourrin en calcul...

Je vous proposerais volontiers de tester les capacités de divers compilateurs avec ma librairie générique sur le calcul d'une FFT (transformée rapide de Fourier). Je suis près à parier qu'ICL les battra tous haut la main !!!...

1)Téléchargez la version 2.1 sur Sourceforge
http://sourceforge.net/projects/genial

2) compiler l'exemple suivant

Code:

---

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

#define HAS_SSE3 // selon processeurs #define FFT_LEVEL 64 #include "signal/fft.h"   int main() { int n=4096; DenseVector<complex<float> >::self X(n,1), Y(n);   double t0=get_clock(); for (int i=0; i<10000; ++i) fft(X,Y); cout << get_clock()-t0 << endl; }

---

3)Voici un exemple de ligne de commande pou GCC. Que les pro-GCC utilisent toute option de compilation qu'ils jugeront utiles.

Code:

---

g++ main.cpp -O2 -msse3 -DNDEBUG -ftemplate-depth-37 -I../genial/genial

---

Et on comparera les résultats!!!

Citation:

---

ma librairie

---

:evilred:

Citation:

---

main.cpp -O2 -msse3

---

pourquoi pas un -O3 ???

Je pense qu'il faut se faire une raison, je suis du même avis que Matthieu, il y a des cas ou ICC est plus rapide, et d'autres non. Mon application de référence pour comparer les deux était un lancer de rayon interactif (avec et sans les intrinsics SSE), avec SSE, la version compilée avec ICC tournait un poil plus rapidement. Sans SSE la différence était quasi nul (en tout cas ne permettant pas de distinguer entre les deux).

Cette année, pour un autre projet, je suis tombé sur un OS avec ICC, le code généré était beaucoup plus lent.

Bref tout ça pour dire que suivant les applications et suivant le code que l'on a le choix du compilateur va dépendre, et est à mon avis secondaire. La meilleure optimisation est dans le choix des algorithmes. Un algo en O(ln n) compilé avec le plus pourri des compilateur sera plus rapide qu'un autre algo compilé avec le dernier compilateur nec plus ultra.

La seule conclusion que j'ai pu tirer de tout ça, c'est que ICC compile le code plus rapidement que gcc et ça j'ai pu le vérifier tout le temps. ;)

Quels sont les avantages et inconvénients d'utiliser le SSE ?

Apperement le code s'exécute plus vite mais si c'était sans contrepartie, cela serait utilisé par défaut non ?
Est-ce comme -ffast-math où l'on perd la précision ?

Merci pour toutes vos réponses.

SSE est un jeu d'instruction SIMD (Single Instruction Multiple Data), permet comme son nom l'indique d'utiliser la même instruction sur un registre 128 bits. Soit donc 2 double ou 4 float par ex.

Ca nécessite d'utiliser soit directement du code assembleur soit par des intrinsics (_mm_xxx_ps ..., où xxx est le nom de l'instruction à exécuter).

Le gros problème est qu'il faut parfois remettre en cause tout son code de façon à utiliser au mieux ces instructions.

Pour SSE, il y a des avantages si les données sont alignées en mémoire et si le processeur les supporte. Mais le compilateur a du mal à les utiliser de lui-même.

Je suis en train de lire un livre sur le code de manière générale, et je retrouve les mêmes remarques que celles que je fais : prendre le bon algorithme pour le problème avant de chercher à optimiser le code ;)

Citation:

---

Envoyé par PRomu@ld

pourquoi pas un -O3 ???

---

Si tu crois que c'est ça qui va faire la différence...

Citation:

---

Envoyé par PRomu@ld

Cette année, pour un autre projet, je suis tombé sur un OS avec ICC, le code généré était beaucoup plus lent.

---

J'ai été moi aussi déçu par les quelques tests que j'ai fait avec ICC sous Linux, y'a 2-3 ans. Les perfs d'ICC était du même ordre de grandeur que GCC. Rien a voir avec ICL sous Windows, aucune idée vraiment pourquoi, ces 2 versions ICC/ICL sont si différentes.
Ne supposez donc pas qu'ICC soit la même chose qu'ICL. Mais après tout c'est peut-être la faute à Linux, je n'en sais rein.

Citation:

---

Envoyé par PRomu@ld

Bref tout ça pour dire que suivant les applications et suivant le code que l'on a le choix du compilateur va dépendre, et est à mon avis secondaire. La meilleure optimisation est dans le choix des algorithmes. Un algo en O(ln n) compilé avec le plus pourri des compilateur sera plus rapide qu'un autre algo compilé avec le dernier compilateur nec plus ultra.

---

Bien sûr, mais c'est du bla-bla. Ici on suppose sur du code identique.

Vous voulez me/vous prouver que GCC est un bon compilateur?
Alors testez mon petit bench, vous n'en aurez pas pour longtemps. Le reste n'est que verbiage...
Je prédis que GCC est hors du coup face à ICL...