Entre les double et les float...

Marsh Posté le 18-04-2003 à 15:30:51

On peut gagner en vitesse de traitement non dans les calculs?

Reply

Marsh Posté le 18-04-2003 à 15:30:51

Reply

Marsh Posté le 18-04-2003 à 15:35:40

Fodger a écrit :

On peut gagner en vitesse de traitement non dans les calculs?

Ben a priori, puisque les doubles utilisent plus de précisions, ils demandent donc plus de mémoire et plus de précisions dans les calculs = plus de calculs => moins de performances.
Mais bon, pour voir la différence, faut déjà un sacré programme ...

---------------
Gérez votre collection de BD en ligne ! ---- Electro-jazzy song ---- Dazie Mae - jazzy/bluesy/cabaret et plus si affinité

Reply

Marsh Posté le 18-04-2003 à 15:40:15

à toi de faire la comparaison

Citation :

11.10 Faut-il préférer les double aux float ?
La vitesse de traitement d'un double n'est pas forcément plus longue qu'un float, cela dépend du compilateur (de ses options) et du processeur. Ainsi avec l'exemple suivant, en remplaçant le typedef par float ou double, on s'aperçoit que sur un Pentium ou un PowerPC, le double est plus rapide à calculer que le float tout en ayant une précision plus grande.

#include <stdio.h>
#include <math.h>

typedef float reel; /* float ou double */

int main(void) {
long i ;
reel d = 3.0 ;

for (i = 0; i < 100000000; i++) {
d = cos(d) ;
}

(void)printf("%f\n", d);
return 0;
}

Le C comprend des instructions mathématiques pour traiter les float directement au lieu de toujours passer par des double depuis la dernière norme (C99). Par exemple il existe cosf() en plus de cos(). En faisant des essais on s'aperçoit que dans notre exemple, le cosf() appliqué à un float devient aussi rapide que le cos() appliqué à un double.

En conclusion, nous pouvons dire qu'il est préférable d'utiliser des double à la place des float, sauf lorsque la place mémoire devient critique.

[benoit@benserver tmp]$ gcc -lm -o float float.c
[benoit@benserver tmp]$ gcc -lm -o double float.c
[benoit@benserver tmp]$ time ./float; time ./double
0.739085

real 0m15.723s
user 0m15.660s
sys 0m0.010s
0.739085

real 0m16.381s
user 0m16.330s
sys 0m0.040s

evidemment, faudrait le faire tourner plusieurs fois, mais tu peux voir qu'il n'y a pas de différence majeur. En fait on utilise les float pour les calculs scientifique où l'on traite beaucoup de données (pour l'anecdote, un copain traite des matrices de 10^6 * 10^6, ce qui l'interesse c'est pas d'avoir quelques chiffres de plus, mais bien d'avoir la matrice la plus garnde possible. La je t'assure, le passage de double en float ce fait sentir: il passe de 7,5To à 3,7To, c'est plus que sensible

Message édité par Taz le 18-04-2003 à 15:58:12

Reply

Marsh Posté le 18-04-2003 à 15:51:00

++Taz a écrit :

Un truc tout à fait interessant

:jap:
Au moins j'aurai apris un truc interessant aujourd'hui.

---------------
Gérez votre collection de BD en ligne ! ---- Electro-jazzy song ---- Dazie Mae - jazzy/bluesy/cabaret et plus si affinité

Reply

Marsh Posté le 18-04-2003 à 15:55:30

T'as choppé ça où?

++Taz a écrit :

à toi de faire la comparaison

Citation :

11.10 Faut-il préférer les double aux float ?
La vitesse de traitement d'un double n'est pas forcément plus longue qu'un float, cela dépend du compilateur (de ses options) et du processeur. Ainsi avec l'exemple suivant, en remplaçant le typedef par float ou double, on s'aperçoit que sur un Pentium ou un PowerPC, le double est plus rapide à calculer que le float tout en ayant une précision plus grande.

#include <stdio.h>
#include <math.h>

typedef float reel; /* float ou double */

int main(void) {
long i ;
reel d = 3.0 ;

for (i = 0; i < 100000000; i++) {
d = cos(d) ;
}

(void)printf("%f\n", d);
return 0;
}

Le C comprend des instructions mathématiques pour traiter les float directement au lieu de toujours passer par des double depuis la dernière norme (C99). Par exemple il existe cosf() en plus de cos(). En faisant des essais on s'aperçoit que dans notre exemple, le cosf() appliqué à un float devient aussi rapide que le cos() appliqué à un double.

En conclusion, nous pouvons dire qu'il est préférable d'utiliser des double à la place des float, sauf lorsque la place mémoire devient critique.

Reply

Marsh Posté le 18-04-2003 à 15:57:30

Fodger a écrit :

T'as choppé ça où?

faq de fclc

Message édité par ToxicAvenger le 18-04-2003 à 15:57:48

Reply

Marsh Posté le 18-04-2003 à 15:59:34

j'appelles ça un testàlacon.

le cos est très long en cycles cpu, une bonne centaine.
de plus si le fpu est en 80 bits ça sortira dans un registre fpu 80 bits. ensuite le cos rebouffera le même registre.

donc le type donné en C/C++ que ce soit float ou double sera inutilisé si le compilateur optimise le code un temps soit peu, et donc qu'il effectues la boucle dans les registres fpu et non la mémoire.

donc ce test a tellement de paramètres non maitrisés que ç'est pas vraiment valable:

pour les x86: mode de précision du fpu ?, d reste-t-il dans un registre ou est-il dégradé dans le format reel en mémoire ?

pour un ppc: vu qu'il me semble que le ppc n'a pas de fonction trigonométriques, quelle est l'implémentation logicielle de cos ?

pour les deux: cos est-il utilisé si fréquemment que c'est une instruction test valable pour dire quelle mode est le plus rapide ?

Reply

Marsh Posté le 18-04-2003 à 16:01:47

c'est bien ce qu'on veut dire: on s'en fout du temps de traitement, il sera sans doute le meme. La seule chose qui importe, c'est la taille des données (voir mon edit)

Message édité par Taz le 18-04-2003 à 16:02:02

Reply

Marsh Posté le 18-04-2003 à 16:03:05

la seule chose que l'on puisse dire, c'est que dans le cas d'un quantité massive de données, le float sera nettement plus rapide, car 2x plus petit que le double, 2x plus petit => 2x moins de bande passante mémoire pour balayer un tableau, 2x plus d'éléments dans une ligne de cache (et donc 2x moins de lignes de caches pour le même nombre d'élements)

Reply

Marsh Posté le 18-04-2003 à 16:03:21

++Taz a écrit :

c'est bien ce qu'on veut dire: on s'en fout du temps de traitement, il sera sans doute le meme. La seule chose qui importe, c'est la taille des données (voir mon edit)

oki on est d'accord

Reply

Marsh Posté le 18-04-2003 à 16:03:21

Reply

Marsh Posté le 18-04-2003 à 16:06:00

BJOne a écrit :

j'appelles ça un testàlacon.

le cos est très long en cycles cpu, une bonne centaine.
de plus si le fpu est en 80 bits ça sortira dans un registre fpu 80 bits. ensuite le cos rebouffera le même registre.

On s'en fout : y a des tables de sin/cos en dur dans les proco [:spamafote]

---------------
"Dieu a exploité tous nos complexes d'infériorité, en commençant par notre incapacité de croire à notre propre divinité." - Emil Michel Cioran

Reply

Marsh Posté le 18-04-2003 à 16:07:00

donc je dirais dans la pratique, pour des ressources qui seont utilisées en "lecture seule" (tableau/structure source), le float est souvant suffisant. dans des calculs intermédiaires, le double est à conseiller (et encore si des résultats intermérdiaires sont conservés dans des registres fpu, la précision peut être supérieure au double):

d'où une petite règle personelle simple:

précision temporaire >= précision finale >= précision de la source.

Message édité par bjone le 18-04-2003 à 16:07:57

Reply

Marsh Posté le 18-04-2003 à 16:07:33

Tetragrammaton IHVH a écrit :

On s'en fout : y a des tables de sin/cos en dur dans les proco [:spamafote]

t'a vu jouer ça où ? :heink:

Reply

Marsh Posté le 18-04-2003 à 16:15:58

BJOne a écrit :

t'a vu jouer ça où ? :heink:

sur ce forum.

---------------
"Dieu a exploité tous nos complexes d'infériorité, en commençant par notre incapacité de croire à notre propre divinité." - Emil Michel Cioran

Reply

Marsh Posté le 18-04-2003 à 16:18:44

Tetragrammaton IHVH a écrit :

sur ce forum.

non, on utilises des tables de précalcul pour aller plus vite, pour justement éviter les fonctions trigo du fpu qui sont couteuses.

mais le cos lui même du fpu est effectué par un algo itératif +ou- compliqué (d'où la centaine de cycles...)

tu ne peux pas utiliser des tables, car ça boufferai trop de rom, et en plus c'est impraticable car imprécis.

pour un jeu, on utilisait avant des tables de précalcul ou tes 360° était sur 256 ou 512 entrées, mais 1° de précision c'est dégueu....

Reply

Marsh Posté le 18-04-2003 à 16:21:29

BJOne a écrit :

non, on utilises des tables de précalcul pour aller plus vite, pour justement éviter les fonctions trigo du fpu qui sont couteuses.

mais le cos lui même du fpu est effectué par un algo itératif +ou- compliqué (d'où la centaine de cycles...)

tu ne peux pas utiliser des tables, car ça boufferai trop de rom, et en plus c'est impraticable car imprécis.

pour un jeu, on utilisait avant des tables de précalcul ou tes 360° était sur 256 ou 512 entrées, mais 1° de précision c'est dégueu....

Y a deja toutes les divisions en dur, alors quelques tables de cosinus, c'est minime. Mais bon, si tu le dis.

---------------
"Dieu a exploité tous nos complexes d'infériorité, en commençant par notre incapacité de croire à notre propre divinité." - Emil Michel Cioran

Reply

Marsh Posté le 18-04-2003 à 16:24:09

Tetragrammaton IHVH a écrit :

Y a deja toutes les divisions en dur, alors quelques tables de cosinus, c'est minime. Mais bon, si tu le dis.

:lol:

les divisions en dur :??:

Reply

Marsh Posté le 18-04-2003 à 16:27:51

Ca c'est pas mal:D...

Reply

Marsh Posté le 18-04-2003 à 16:28:45

BJOne a écrit :

donc je dirais dans la pratique, pour des ressources qui seont utilisées en "lecture seule" (tableau/structure source), le float est souvant suffisant. dans des calculs intermédiaires, le double est à conseiller (et encore si des résultats intermérdiaires sont conservés dans des registres fpu, la précision peut être supérieure au double):

d'où une petite règle personelle simple:

précision temporaire >= précision finale >= précision de la source.

Pour les comparaisons d'égalité, mieux s'abstenir à cause des erreurs d'arondi.

Reply

Marsh Posté le 18-04-2003 à 16:34:45

vive les developpements limités

Reply

Marsh Posté le 18-04-2003 à 16:35:21

Fodger a écrit :

Pour les comparaisons d'égalité, mieux s'abstenir à cause des erreurs d'arondi.

heu vi mais je compare pas des variables flottantes là, je parle de précision...

par exemple je sais pas, pour un système lié à un terrain, tu stoques tes altitudes en short int 16 bits, pour tes calculs temporaires tu ramènes ça en float ou double et idem pour ce qui est à considérer comme calcul final.

Reply

Marsh Posté le 18-04-2003 à 16:41:05

++Taz a écrit :

vive les developpements limités

c'est un peu ça l'idée

Reply

Marsh Posté le 18-04-2003 à 16:44:46

Le choix peut aussi être dû aux optimisations possibles avec les unités spécifiques:
Altivec et SSE n'utilisent que des floats.
SSE2 permet l'utilisation de flottants 64bits mais y en a que 2 par registre de 128 bits.

Reply

Marsh Posté le 18-04-2003 à 19:10:18

BJOne a écrit :

:lol:

les divisions en dur :??:

Ah ouais, d'accord, je croyais que j'avais affaire à un spécialiste...
Renseigne toi un minimum avant de poster des ":lol:" à tout va.

Mots clés : pentium, bug, FDIV

Message édité par Tetragrammaton IHVH le 18-04-2003 à 19:10:59

---------------
"Dieu a exploité tous nos complexes d'infériorité, en commençant par notre incapacité de croire à notre propre divinité." - Emil Michel Cioran

Reply

Marsh Posté le 18-04-2003 à 22:35:20

Tetragrammaton IHVH a écrit :

Ah ouais, d'accord, je croyais que j'avais affaire à un spécialiste...
Renseigne toi un minimum avant de poster des ":lol:" à tout va.

Mots clés : pentium, bug, FDIV

et ? :heink:

donne le lien...

il y a probablement des tables de précalcul utilisées dans les cpu, mais "Y a deja toutes les divisions en dur" est sujet à interprétation bizarre...

Reply

Marsh Posté le 18-04-2003 à 22:42:42

oki dans le cas du pentium, il y a une table de précalcul de 1066 entrées. mais le terme "Y a deja toutes les divisions en dur" n'est pas du -tout- approprié oki :jap:

car même utilisant des tables de précalcul, la divsion, racine carré et la trigo utilisent des algo itératifs...

Message édité par bjone le 18-04-2003 à 22:47:21

Reply

Marsh Posté le

Reply

Entre les double et les float...

Sujets relatifs:

Leave a Replay