Coût à l'exécution d'un transtypage ou d'un typedef

Le
btzaf
Bonjour,

Encore trois questions stupides du matin.

1) Soit le code suivant :

double d;
float f = 3.14;
d = f;

Quel sera l'importance du coût à l'exécution du transtypage implicite,
c'est-à-dire est-ce qu'il aurait mieux valu que f soit tout de suite un
double ?

2) Est-ce que le fait d'utiliser un typedef entraîne un coût à
l'exécution par rapport à l'utilisation du type de base. En d'autres
termes est-ce que le code généré sera identique à celui qui
n'utiliserait que le type de base (du moins du point de vue de la
performance)

Merci d'avance.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
James Kanze
Le #18566581
On Feb 3, 8:52 am, btzaf
Encore trois questions stupides du matin....



1) Soit le code suivant :



double d;
float f = 3.14;
d = f;



Quel sera l'importance du coût à l'exécution du transtypage
implicite, c'est-à-dire est-ce qu'il aurait mieux valu que f
soit tout de suite un double ?



Le coût dépendrait étroitement de la machine et du
compilateur ; on ne peut rien en dire d'office. En revanche, le
résultat ne serait pas le même si f était double.

En général, on conseille de n'utiliser que double sauf quand on
a des problèmes de place.

2) Est-ce que le fait d'utiliser un typedef entraîne un coût à
l'exécution par rapport à l'utilisation du type de base. En
d'autres termes est-ce que le code généré sera identique à
celui qui n'utiliserait que le type de base (du moins du point
de vue de la performance)



A priori, oui.

Mais s'intéresser aux temps d'exécution à ce niveau-là est en
général contre-productif. Écrire du code correct, d'abord. Puis,
si ce n'est pas assez rapide, utiliser un profiler pour
déterminer où se trouvent les goulots d'étranglement, et les
améliorer.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Guillaume GOURDIN
Le #18567761
> En général, on conseille de n'utiliser que double sauf quand on
a des problèmes de place.



Je dirais aussi quand on a des problèmes de performences. J'ai travaillé
dans le jeu vidéo, et même si je ne codais pas du code bas niveau, je
sais que le 'float' est le type de base utilisé, je pense à cause de
problème de performances.

G.
Michael DOUBEZ
Le #18568281
Guillaume GOURDIN wrote:
En général, on conseille de n'utiliser que double sauf quand on
a des problèmes de place.



Je dirais aussi quand on a des problèmes de performences. J'ai travaillé
dans le jeu vidéo, et même si je ne codais pas du code bas niveau, je
sais que le 'float' est le type de base utilisé, je pense à cause de
problème de performances.



Ça dépends des processeurs. Sur certains, en fonction de la taille des
registres, le double peut être plus rapide.

Dans les jeux vidéo je suppose que l'utilisation du float est plus en
rapport avec la taille mémoire (maillages), peut être pour des raisons
de taille de cache ou pour le dialogue avec un GPU (qui travaillent
encore en 32 bits en général).

--
Michael
Fabien LE LEZ
Le #18570101
On Tue, 03 Feb 2009 08:52:01 +0100, btzaf
2) Est-ce que le fait d'utiliser un typedef entraîne un coût à
l'exécution par rapport à l'utilisation du type de base.



D'après ce que j'ai pu voir comme messages d'erreurs, les compilos ont
tendance à traiter typedef un peu comme #define : ils remplacent le
nouveau type par sa définition avant la compilation proprement dite.

Donc non, aucune différence à l'exécution.

M'enfin bon, de toute façon, il y a de bonnes chances pour que de si
petites différences soient noyées sous le bruit de fond. Avec deux ou
trois niveaux de cache processeur (L1, L2, L3) et plusieurs processus
qui l'utilisent en même temps, et mille autre détails de ce style,
bien malin celui qui saura quelle influence telle ou telle petite
modification du code aura sur la vitesse d'exécution.

Je t'encourage toutefois à l'intéresser de près au compilateur C++
d'Intel, dont l'optimiseur est explicitement prévu pour prendre en
compte toutes les spécificités du x86 ou AMD64.
Alain Ketterlin
Le #18570571
btzaf
Encore trois questions stupides du matin....



J'en ai vu que 2...

1) Soit le code suivant :

double d;
float f = 3.14;
d = f;

Quel sera l'importance du cout à l'exécution du transtypage
implicite, c'est-à-dire est-ce qu'il aurait mieux valu que f soit
tout de suite un double ?



Ce n'est pas le problème du langage, cela va dépendre du jeu
d'instruction. Et même s'il te semble implicite, il y a des chances
qu'il soit tout à fait explicite dans le code produit (sur x86_64, ce
sera un cvtss2sd). Regarde le code pour savoir.

2) Est-ce que le fait d'utiliser un typedef entraîne un coût à
l'exécution par rapport à l'utilisation du type de base.



Les typedef n'ont aucune influence sur le code produit, ils n'ont de
sens qu'au sein du compilateur (par rapport au type de base, je veux
dire). Tu peux donc en mettre autant que tu veux.

-- Alain.
Marc
Le #18574461
btzaf wrote:

1) Soit le code suivant :

double d;
float f = 3.14;
d = f;

Quel sera l'importance du coût à l'exécution du transtypage implicite,
c'est-à-dire est-ce qu'il aurait mieux valu que f soit tout de suite un
double ?



Niveau précision, oui, il aurait mieux valu. Niveau temps d'exécution, il
y a des chances que le compilateur fasse le calcul lui-meme et qu'il ne
reste rien a faire a l'exécution (la légalité de cette optimisation
dépend de choses compliquées sur les modes d'arrondis). Si l'optimization
n'a pas lieu, il y aura effectivement un certain cout (faible).

2) Est-ce que le fait d'utiliser un typedef entraîne un coût à
l'exécution par rapport à l'utilisation du type de base. En d'autres
termes est-ce que le code généré sera identique à celui qui
n'utiliserait que le type de base (du moins du point de vue de la
performance)



Aucun cout, un typedef dit au compilateur que 2 types sont identiques, et
il les traite effectivement comme identiques en générant le meme code. Le
typage n'a de cout a l'exécution que pour les objets/méthodes virtuels,
ou une partie du typage est dynamique.

Mon principal conseil est d'oublier toutes ces histoires de détails de
performance. L'autre jour je regardais un bout de code, et remplacer -a<b
par a>-b (a et b sont des double) dans une branche de code jamais
exécutée a ralenti le programme de 30%. Avec un tel aléa, mieux vaut se
concentrer sur l'algorithmique...
Wykaaa
Le #18583261
Michael DOUBEZ a écrit :
Guillaume GOURDIN wrote:
En général, on conseille de n'utiliser que double sauf quand on
a des problèmes de place.



Je dirais aussi quand on a des problèmes de performences. J'ai
travaillé dans le jeu vidéo, et même si je ne codais pas du code bas
niveau, je sais que le 'float' est le type de base utilisé, je pense à
cause de problème de performances.



Ça dépends des processeurs. Sur certains, en fonction de la taille des
registres, le double peut être plus rapide.



J'ai connu une machine qui disposait de registres scientifiques en
double précision.
Sur cette machine, les calculs en float étaient moins performants qu'en
double.

Dans les jeux vidéo je suppose que l'utilisation du float est plus en
rapport avec la taille mémoire (maillages), peut être pour des raisons
de taille de cache ou pour le dialogue avec un GPU (qui travaillent
encore en 32 bits en général).



James Kanze
Le #18576931
On Feb 3, 11:19 am, Guillaume GOURDIN
> En général, on conseille de n'utiliser que double sauf quand on
> a des problèmes de place.



Je dirais aussi quand on a des problèmes de performences.



La recommendation de préférer double avait, au départ, une
motivation d'optimisation, au moins en partie ; sur un PDP-11,
travailler en double était plus rapide qu'en float. Selon les
mesures que j'ai fait sur un Sparc (assez ancien), il n'y a
aucune différence, au moins en ce qui concerne les opérations de
base. (Quand on travaille avec des tableaux, le fait qu'une page
de mémoire virtuelle peut en contenir deux fois plus de valeurs
peut bien faire une différence.)

Mais tout dépend du processeur, et je connais (ou connaissais)
des processeurs où l'arithmétique double était bien plus lente.

J'ai travaillé dans le jeu vidéo, et même si je ne codais pas
du code bas niveau, je sais que le 'float' est le type de base
utilisé, je pense à cause de problème de performances.



J'imagine plutôt à cause de la place. Un image n'est pas
particulièrement petit. Mais comme j'ai dit, ça dépend du
processeur.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Alain Ketterlin
Le #18577321
James Kanze
[...]
J'ai travaillé dans le jeu vidéo, et même si je ne codais pas
du code bas niveau, je sais que le 'float' est le type de base
utilisé, je pense à cause de problème de performances.



J'imagine plutôt à cause de la place. Un image n'est pas
particulièrement petit. Mais comme j'ai dit, ça dépend du
processeur.



Effectivement, il y a encore pas mal de GPU qui travaillent en simple
précision (float), et sur lesquelles manipuler des double fait tomber
significativement les performances.

-- Alain.
btzaf
Le #18578271
Merci à tous de vos réponses très intéressantes.

J'en tire donc la conclusion qu'une façon de procéder qui peut paraître
raisonnable, lorsque ces détails peuvent devenir important, consisterait
à utiliser dans les premières phases de développement une écriture du type :
typedef double mon_type;

puis lorsqu'on en est à couper les cheveux en 4 et à faire des tests sur
différentes plates-formes à entourer cette déclaration de type dans des
#ifdef relatifs à la plateforme.

Merci encore !
Publicité
Poster une réponse
Anonyme