Discussion :

[NairodDorian]

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

Non le code de la fonction demo est :

Code :

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

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 ?

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.

[three minute hero]

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 !

[three minute hero]

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 :

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

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 :

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

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

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

[NairodDorian]

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

Code :

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

1
2
3
4
5
 
push ebp
mov ebp, esp
...
pop ebp

Hum... hum...

MSC++ génère :

Code :

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

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 :

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

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.

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

[three minute hero]

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

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 ?

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.

[three minute hero]

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 .

[wiztricks]

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

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

[three minute hero]

Voilà voilà :

Code :

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

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.

[loufoque]

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 :

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

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

[three minute hero]

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

Code :

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

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 .

[wiztricks]

Voilà voilà :

Code :

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

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

[Matthieu Brucher]

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

[NairodDorian]

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

Oui effectivement

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

Non pas depuis la version 2005.

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.

Qui mieux que Renault pour entretenir votre Renault?

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

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

[Matthieu Brucher]

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

[Charlemagne]

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 :

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

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 :

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

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

Et on comparera les résultats!!!

[PRomu@ld]

ma librairie

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.

[Nanoc]

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.

[PRomu@ld]

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.

[Matthieu Brucher]

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

[Charlemagne]

pourquoi pas un -O3 ???

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

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.

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