int vs double: qui est le plus rapide?

Version imprimable

22/03/2006, 18h20
Chewbi

int vs double: qui est le plus rapide?

Bonjour,

Tout est dans le titre mais je m'explique néanmoins: j'écris un jeu de dames, et on nous demande de faire le programme le plus performant possible; j'ai essayé avec des 'float' (comme variables dans la fonction d'evaluation), puis avec des 'int": moralité = ça semble plus rapide avec des float (?!)

Ca me semble étrange, d'où ma question: double>float>int, ou..?

Merci d'avance!
Benjamin
22/03/2006, 18h23
Pragmateek

Citation:

ça semble plus rapide avec des float

C'est à dire?

Quels tests ont été faits pour évaluer la vitesse?
22/03/2006, 18h23
silverhawk.os

double / float / ou int, ça dépend des calculs que tu fais !
Mais à priori, tu ne devrais pas noter de différence... c'est pas perceptible, sauf pour des applications très spécifiques.

La règle, tu fais des opérations sur des entiers : int
sur de la virgule flotante -> float ou double suivant la grandeur des nombres que tu manipules.

Mais côté optimisation, cherche ailleurs !
22/03/2006, 18h33
Chewbi

tests realises:

le programme calcule a 4 demi-coups de profondeur avec des flottants (ie tous les calculs, réalisés un nombre exponentiel de fois, sont faits avec des flottants dans la fonction d'évaluation), puis à la meme profondeur avec des entiers (toujours la meme fonction d'évaluation, traffiquée pour travailler avec des entiers).

Resultat: un gain de temps d'un facteur 2 à 4 pour les flottants (d'où ma question, désolé si elle est bete !)

je viens d'essayer avec des doubles, c'est encore plus rapide que les float; bon voici ma fonction d'evaluation (appelee sur tous les noeuds de l'arbre, donc souvent malgré l'alpha-beta ^^)

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
 
 
double eval=val;   
       int matosW=0,matosB=0;
       for (int i=9; i>=0; i--)
       	  for (int j=4; j>=0; j--) {
       		 if (damier[5*i+j]>0) matosW++; 
       		 else if (damier[5*i+j]<0) matosB++; 
          }	
 
       // recherche de pions isoles "loins" sur colonnes a horizon occupe (heuristique qui semble OK)
       // (poids plus faible des que le materiel est trop reduit)
 
       /* --> evite les bourdes du genre pion trop avance perdu */
 
       int isolW=0,isolB=0;
       for (int i=4; i>=0; i--) {
           for (int j=7; j>=4; j--)
             if (damier[j*5+i]==VP)
               if (j&1) // rangee paire
                  if (i!=0)
                     if (damier[j*5+i+5]==0 && damier[j*5+i+6]==0 && damier[j*5+i-5]==0 && damier[j*5+i-4]==0)
		     	for (int k=j+1; k<=9; k++) 
				if (damier[5*j+i]<0) {
					isolW++;
					break;
				}
               else 
                  if (i!=4)
                     if (damier[j*5+i+4]==0 && damier[j*5+i+5]==0 && damier[j*5+i-6]==0 && damier[j*5+i-5]==0) 
		     	for (int k=j+1; k<=9; k++) 
				if (damier[5*j+i]<0) {
					isolW++;
					break;
				}
           for (int j=5; j>=2; j--)  
	     if (damier[j*5+i]==-VP)
               if (j&1) // rangee paire
                  if (i!=0)
                     if (damier[j*5+i+5]==0 && damier[j*5+i+6]==0 && damier[j*5+i-5]==0 && damier[j*5+i-4]==0) 
		     	for (int k=j-1; k>=0; k--) 
				if (damier[5*j+i]>0) {
					isolB++;
					break;
				}
               else 
                  if (i!=4)
                     if (damier[j*5+i+4]==0 && damier[j*5+i+5]==0 && damier[j*5+i-6]==0 && damier[j*5+i-5]==0) 
		     	for (int k=j-1; k>=0; k--) 
				if (damier[5*j+i]>0) {
					isolB++;
					break;
				}
	   }
       eval-=(double)(isolW*matosW-isolB*matosB)/80;       
 
       // test de l'équilibre/harmonie global(e) du damier
       // on compte le nombre de pions sur chaque colonne: 
       // malus s'ils sont très !=
       // utilisé en fonction de l'avancement de la partie
       // ATTENTION: a desactiver (ou inverser) si on veut une partie de flanc, ou centrale
 
   /* --> permet de garder un jeu homogene */
 
  /*     int nbColW[5]={0,0,0,0,0}; 
       int nbColB[5]={0,0,0,0,0};
       int sommeW=0,sommeB=0;
       for (int i=4; i>=0; i--)
             for (int j=9; j>=0; j--)
                  if (damier[i+j*5]>0) {
                     nbColW[i]++;
                     sommeW++;
                  } 
                  else if (damier[i+j*5]<0) {
                     nbColB[i]++;
                     sommeB++;
                  } 
             // calcul des variances
             int varW=0,varB=0;
             for (int i=4; i>=0; i--) {
                 varW+=(sommeW-nbColW[i])*(sommeW-nbColW[i]);
                 varB+=(sommeB-nbColB[i])*(sommeB-nbColB[i]);
             }
       eval-=(varW*matosW-varB*matosB);///70;  */
 
    // recherche des colonnes vides
 
    /* --> evite tout simplement que l'adversaire fasse dame trop vite */ 
 
       bool colVidW[5]={true,true,true,true,true};
       bool colVidB[5]={true,true,true,true,true};
       for (int i=4; i>=0; i--) 
            for (int j=9; j>=0; j--) 
                  if (damier[j*5+i]>0) {
                     colVidW[i]=false;
                     break;
                  }
                  else if (damier[j*5+i]<0) {
                     colVidW[i]=false;
                     break;
                  }
       for (int i=4; i>=0; i--) {
              if (colVidW[i]) eval-=40;//4;
              if (colVidB[i]) eval+=40;//4; 
       } 
 
	// on donne plus de poids aux pion avances sur les bords
 
	/* --> conserve des avant-postes avantageux */
 
	int avanceW=0,avanceB=0;
	if (damier[40]==VP) avanceW+=2;
	if (damier[39]==VP) avanceW++;
	if (damier[30]==VP) avanceW++;
	if (damier[29]==VP) avanceW++;
 
	if (damier[20]==-VP) avanceB++;
	if (damier[19]==-VP) avanceB++;
	if (damier[10]==-VP) avanceB++;
	if (damier[9]==-VP) avanceB+=2;
       eval+=(double)(avanceW*matosW-avanceB*matosB)/80;
 
	 // comptage des degrés de liberté selon l'avancement de la partie
 
     /* --> evite de se mettre en zugzwang */ 
 
    int degLibW=0,degLibB=0;
    int auxW,auxB;
    for (int i=9; i>=0; i--) {
      	   auxW=0; auxB=0;
      	   for (int j=4; j>=0; j--)
      	       if (damier[i*5+j]>0) auxW++;
      	       else if (damier[i*5+j]<0) auxB++; 
      	   degLibW+=(i+1)*auxW;
      	   degLibB+=(10-i)*auxB;
   }
   eval+=(double)((20-(int)partie.size())*(degLibW-degLibB))/50; // "20" est sensé etre le nb de demi-coups à mi-partie..
 
     // le critere suivant est pris en compte que s'il n'y a pas de dames avec une partie pas trop avancee
     if (matosW<=10 || matosB<=10 || (int)partie.size()>40) return eval;
     for (int i=9; i>=0; i--)
     	for (int j=4; j>=0; j--)
		if (damier[i*5+j]==VD || damier[i*5+j]==-VD) return eval;
 
     // recherche des mauvaises configurations en V ou deux pions adverses forment une pente du V
     // surtout utilise en debut/milieu de partie
 
     /* --> permet d'eviter certaines recaptures dans de mauvaises conditions */
 
     int nbConfW=0,nbConfB=0;
     for (int i=6; i>=3; i--)
     	for (int j=3; j>=1; j--)
		if (i&1) // toujours la distinction rangee paire/impaire
			if ((damier[i*5+j]>0 && damier[i*5+j+5]<0 && damier[i*5+j-1]<0) || 
			   (damier[i*5+j]>0 && damier[i*5+j+6]<0 && damier[i*5+j+1]<0))	nbConfW++;
			else if ((damier[i*5+j]<0 && damier[i*5+j-5]>0 && damier[i*5+j-1]>0) || 
			   (damier[i*5+j]<0 && damier[i*5+j-4]>0 && damier[i*5+j+1]>0))	nbConfB++;  	
	  	else
			if ((damier[i*5+j]>0 && damier[i*5+j+4]<0 && damier[i*5+j-1]<0) || 
			   (damier[i*5+j]>0 && damier[i*5+j+5]<0 && damier[i*5+j+1]<0))	nbConfW++;
			else if ((damier[i*5+j]<0 && damier[i*5+j-6]>0 && damier[i*5+j-1]>0) || 
			   (damier[i*5+j]<0 && damier[i*5+j-5]>0 && damier[i*5+j+1]>0))	nbConfB++;
     eval-=(float)(nbConfW*matosB-nbConfB*matosW)/80;

PS: les "/80" sont mauvais, il faut mettre d'autres poids (là il joue mal avec ceux-ci..)

22/03/2006, 18h47
BigNic

difficile à dire comme cela !
A quoi sert tes données ?
De quel capacité ont-ils besoin ?
etc...
Sinon je dirais d'une manière très générale plus ton format a d'octets plus il est lent. Et int étant le format "natif" le proc est fait pour faire des opération dessus. De plus sauf si je me trompe, les nombres à virgule flotante sont toujours plus long à traiter que les autres, car les opérations à faire sont plus complexe.
Mais bon ça dépend de ton archi, d'ailleurs il parait que sur solaris 10 ils vachement bossé sur le sujet !
De toute façon comme l'on dit beaucoup d'autre avant moi, pour savoir ce qui prend du temps il faut tester !
Et ceci étant une des activités de mon équipe au boulot je peux t'assurer que c'est 100% vrai.

Coder orienté perf est une perte de temps et une source de bug. Je ne dit pas qu'il faut faire n'importe quoi et après on voit. Il faut penser à l'archi et la conception de ton soft histoire de ne pas te trouver dans des impasses plus tard, mais entre 2 blocs d'instructions souvent il faut tester pour savoir lequel est le plus performant.
Un autre truc est qu'il vaut mieux optimiser trois petites lignes de code qui sont appeler tout les temps, que un gros blocs d'une centaine appeler 1 fois à l'initialisation du soft.
[Mode=pinailleur] :twisted:
Quand au fait de rendre un appli performante à tes profs, je te "conseil" de remplacer toutes tes fonctions (surtout celle peut appelées) par des macros. Je remplacerai tout mes if else par des opérateur ternaire ?: et plein de truc qui rendent le code imbitable mais vachement rapide. Et si ils osent faire une remarque tu leur dits que la prochaine fois ils demandent maintenanble et performant.

Une autre alternative consite aussi à faire des tests sérieux sur quoi coûte quoi. Eux de toutes façon ne le feront pas, donc ne pourront contester.
[/Mode]

[Mode=prof]
je pense que par le plus performant possible, tes profs te demande de choisir les bons algo. La vitesse de traitement d'un int ou un float sont certainement très négligeable si ton algo est mauvais.
[/mode]
22/03/2006, 19h00
Chewbi

Oki merci :-)

M'en vais optimiser mon alpha-beta et bosser mes algos parallèles, ça vaut mieux apparemment ^^
22/03/2006, 19h41
Matthieu Brucher

Fais un vrai profiling de ton code, et fais des moyennes de temps d'exécution avec au moins 10 itérations avec les mêmes données.

Je code un moteur physique, j'ai fais en sorte qu'on puisse choisir, à la compilation s'il on utilisait des int, long ou long long comme entier et float, double, long double comme flotant....
Résultat, pour une même scène (donc calculs similaires) :
Code:

1 2 3 4 5 6 7 8 9 (int/float) 96 fps (int/double) 135 fps (int/long double) 92 fps (long/float) 91 fps (long/double) 122 fps (long/long double) 87 fps (long long/float) 85 fps (long long/double) 90 fps (long long/long double) 81 fps
(nombre de fps moyen....)
On peut voit maintenant quel type de couple entier flotant j'utilise..
J'ai été déçu par les float, je croyais vraiment qu'il allaient donner de meilleurs perf....

22/03/2006, 22h05
loufoque

long long n'existe pas en C++.
À part ça, tu compiles avec quelles optimisations ? Y'a des trucs spéciaux pour le calcul flottant sur x86.
22/03/2006, 22h07
Pragmateek

Citation:

long long n'existe pas en C++.

Si ça marche!
22/03/2006, 22h09
silverhawk.os

Ouaip...
si mes souvenirs sont bons, long long -> long :lol:
22/03/2006, 22h12
loufoque

Citation:

Envoyé par seriousme

Citation:

long long n'existe pas en C++.

Si ça marche!

C'est pas dans la norme de C++.
C'est dans C99.
22/03/2006, 22h12
Pragmateek
Code:

1 2 long long a=0; cout<<sizeof(a)<<endl;
Renvoie 8.

Et long fait 4.

Donc c'est bon!

EDIT:

Citation:

C'est dans C99.

Merci de la précision.

Donc c'est du C?
22/03/2006, 22h15
loufoque

En mode pedantic avec ton code on obient

Citation:

erreur: ISO C++ does not support ‘long long’
22/03/2006, 22h17
Pragmateek

Citation:

pedantic

Connais pas!

EDIT: Avec Dev-C++ sous Windows en pedantic j'ai rien.
22/03/2006, 23h26
Luc Hermitte

Citation:

Envoyé par BigNic

[Mode=prof]Je pense que par le plus performant possible, tes profs te demande de choisir les bons algo. La vitesse de traitement d'un int ou un float sont certainement très négligeable si ton algo est mauvais.[/mode]

En mode collègue de travail, c'est pire. J'ai pas envie de maintenir des pinaillages pareils pendant que le collègue sera en vacance, ou après qu'il ait changé d'affectation.

Sinon, les diff observées vont dépendre des architectures sur lesquelles tu vas tourner. Utiliser un compilo doué pour les optims fera encore plus de différence.
Et effectivement, l'alpha-beta consomme suffisament pour que ce genre d'optims ne servent à rien. De même que le [i*N+j], le compilo est bien plus intelligent que ce que tu crois. Il y a autre chose à faire que d'obscurcir un code de la sorte, ou en déroulant les boucles à la main pour gérer le pipeline, ou encore gérer le cache mémoire.

EDIT: s/des/ce genre d'/
22/03/2006, 23h35
Rafy

Citation:

Envoyé par loufoque

À part ça, tu compiles avec quelles optimisations ? Y'a des trucs spéciaux pour le calcul flottant sur x86.

hum j'ai retiré l'optimisation globale de Visual. Donc c'est juste optimisé pour la vitesse... (coche dans les options de Visual)
J'ai compilé le moteur pour chaque couple (compilé une librairie en fait)
puis j'ai utilisé ces librairies avec le même code dans une application...
J'ai répondu a ta question ?
23/03/2006, 14h43
Chewbi

Citation:

Envoyé par loufoque

long long n'existe pas en C++.
À part ça, tu compiles avec quelles optimisations ? Y'a des trucs spéciaux pour le calcul flottant sur x86.

J'utilise les optimisations suivantes (j'ai essayé d'en mettre d'autres mais ça ne semble pas accélérer plus):

-O3
-funroll-loops
-foptimize-register-move

avec g++ sur Unix (je ne sais pas exactement quel système d'exploitation mon école utilise :/ [ENSIMAG])

Merci à tous, je vois maintenant que le problème est beaucoup plus compliqué que ce que je pensais, la vitesse dépendant beaucoup de l'architecture et du programme.
23/03/2006, 14h46
Chewbi

oops la question ne s'adressait apparemment pas à moi ;o)) tant pis je laisse le message :)
23/03/2006, 15h48
Matthieu Brucher

Oui, laisse, c'est intéressant tout de même ;)
23/03/2006, 19h19
loufoque

Citation:

Envoyé par Chewbi

avec g++ sur Unix (je ne sais pas exactement quel système d'exploitation mon école utilise :/ [ENSIMAG])

Je parlais d'optimisations spécifiques à x86 pour le calcul flottant (SSE etc.)
En faisant cat /proc/cpuinfo tu devrais pouvoir voir ce que tu as comme processeur.
Et tu peux savoir quel type d'Unix tu as en faisant uname -a
24/03/2006, 11h16
Chewbi

J'obtiens la réponse suivante après un uname -a:

Linux ensibull 2.6.7-BAS3V13-16k-pagesize #1 SMP Wed Oct 6 11:39:33 CEST 2004 ia64 ia64 ia64 GNU/Linux pour ensibull

et: AIX ensibm 2 5 005A471A4C00 unknown unknown AIX pour ensibm

C'est un peu obscur pour moi ^^
25/03/2006, 02h58
loufoque

Apparemment le premier c'est du GNU/Linux pour Intel Itanium et le second c'est de l'AIX (unix d'IBM qui doit tourner sur du matos spécifique à IBM).
Le tout customisé.

Donc côté optimisations matérielles pour ce genre de calcul va falloir te documenter par toi-même, je connais pas trop.