Coût à l'exécution d'un transtypage ou d'un typedef
10 réponses
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)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
James Kanze
On Feb 3, 8:52 am, btzaf wrote:
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
On Feb 3, 8:52 am, btzaf <bt...@free.fr> wrote:
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:james.kanze@gmail.com
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
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
> 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.
> 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.
> 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
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
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).
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
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.
On Tue, 03 Feb 2009 08:52:01 +0100, btzaf <btzaf@free.fr>:
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.
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
btzaf writes:
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.
btzaf <btzaf@free.fr> writes:
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.
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
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...
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...
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
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).
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).
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
On Feb 3, 11:19 am, 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.
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
On Feb 3, 11:19 am, Guillaume GOURDIN <tr...@hotmail.com> 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.
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:james.kanze@gmail.com
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
> 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
James Kanze writes:
[...]
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.
James Kanze <james.kanze@gmail.com> writes:
[...]
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.
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
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 !
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.
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.
