Discussion :

[me_myself]

Bonjour,

J'ai de nombreux calculs où je dois soit faire un calcul de doubles casté dans un integer, ou soit inversement faire une opération comme une division d'integers vers un double.

Rien de bien compliqué certes, mais multiplié par des millions d'opérations, cela peut y avoir des variations considérables de temps de calcul.

Quels sont toutes les différentes options et leur 'coût' en temps de calcul?


Merci d'avance

bv

[loufoque]

Un cast créé une nouvelle variable, éventuellement temporaire.

[me_myself]

OK, mais si je ne fais pas un cast explicite, je laisse le compilateur faire, il me donne un warning (possible data loss) mais évidemment ça marche.

Mais comment faire proprement et le plus efficacement?

Merci

bv

[Médinoc]

L'affectation d'un nombre à virgule flottante dans un entier, avec ou sans cast explicite, entrainera toujours la conversion à un moment ou à un autre.

"On" m'a dit qu'une conversion entre flottant et entier était plus couteuse qu'une simple opération de calcul flottant, et qu'il fallait réduire les conversions au minimum...

[Jan Rendek]

OK, mais si je ne fais pas un cast explicite, je laisse le compilateur faire, il me donne un warning (possible data loss) mais évidemment ça marche.

Mais comment faire proprement et le plus efficacement?

Merci
bv

Implicite ou explicite, la transformation d'un entier en double ou l'inverse sera rigoureusement la même. Le cast explicite indique au compilo que tu connais les conséquences (nombre tronqué, etc...), ce qui rend le warning inutile.

La seule solution c'est de revoir l'algorithme pour limiter les transtypages au strict minimum.

[bricerive]

Si tu dois vraiment faire du cast de double vers int en grande quantite, je te recommande cette petite merveille:
(Pour ceux qui voient vraiment pas comment ca peut marcher, au point de croire que ca marche pas, je ne saurais trop recommander de faire un essai)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
#define D2I_CONVERSION_FACTOR (1.5 * 4503599627370496.0)
inline int d2i(double val)
{
    union {
        int i[2];
        double d;
    } dlong;
    dlong.d = val + D2I_CONVERSION_FACTOR;
    return dlong.i[0];
}

C'est plus rapide qu'un cast standard par un facteur de 8, et meme plus rapide qu'un cast en assembleur du genre:

Code :

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

1
2
3
4
5
6
7
 
double d;
int val;
__asm {
  fld qword ptr[d]
  fistp dword ptr[val]
}

J'ai verifie moi-meme.

les limitations du truc:
-Tres difficile a comprendre (je peux filer une explication si tu cale et que ca t'interesse).
-Les ints doivent etre en 32 bits
-Les doubles doivent etre en representation standard (1/11/52)
-Marche tel quel uniquement sur une machine big-endian
-Pas du tout du tout de verification ou de traitement d'erreurs.
Les trois premieres peuvent etre contournees, la derniere non :-)

Il est possible de faire la fonction inverse ;-)

[Médinoc]

Ça joue sur la représentation standard.
Je suppose que ton D2I_CONVERSION_FACTOR sert à forcer l'exposant à une valeur connue...

Je me rappelle avoir écrit une macro qui, au lieu de passer par une union, faisait du transtypage de pointeur pour pouvoir accéder aux données du double en tant qu'entier...

Code :

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

1
2
3
4
5
6
7
8
9
10
#define DBL2LONG_0(dbl) (reinterpret_cast< long *>(&(dbl))[0])
#define DBL2LONG_1(dbl) (reinterpret_cast< long *>(&(dbl))[1])
 
#ifdef BIG_ENDIAN //Ou tout autre #define dépendant de l'endianness
#define DBL2LONG_H(dbl) DBL2LONG_0(dbl)
#define DBL2LONG_L(dbl) DBL2LONG_1(dbl)
#else
#define DBL2LONG_H(dbl) DBL2LONG_1(dbl)
#define DBL2LONG_L(dbl) DBL2LONG_0(dbl)
#endif

De là, si le double est en représentation standard, on peut accéder à sa mantisse et à son exposant...

[Mat.M]

(Pour ceux qui voient vraiment pas comment ca peut marcher, au point de croire que ca marche pas, je ne saurais trop recommander de faire un essai)

Code :

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

1
2
3
 
    dlong.d = val + D2I_CONVERSION_FACTOR;
}

Je suis très très sceptique sur le fait que cela soit plus performant

Parmi les inconvénients de cette méthode, j'ajouterai :
- Aucune garantie que ça fasse quoi que ce soit. Ecrire dans un membre d'une union et lire dans un autre est un comportement indéfini. Il se peut que ça marche sur une certaine machine, avec une certaine version d'un compilateur, avec certaines options de compilation, pendant certaines phases de la lune, mais rien n'est moins sur.

100% d'accord mais quel est le rapport avec les phases de la lune ?