déréférencement du pointeur type-punned brisera les strictes d'aliases

Bonjour,

Voici un code que j'ai trouvé sur le net pour calculer rapidement la racine carré :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

inline float CMathFct::squareRoot(float number) { long i; float x, y; const float f = 1.5F;   x = number * 0.5F; y = number; i = * ( long * ) &y; //warning ici i = 0x5f3759df - ( i >> 1 ); y = * ( float * ) &i; //warning ici y = y * ( f - ( x * y * y ) ); y = y * ( f - ( x * y * y ) ); return number * y; }

---

Quand je compile ce code avec l'option -O2 de g++, tout se passe bien mais quand je compile avec l'option -O3, j'ai ce warning :
"attention : déréférencement du pointeur type-punned brisera les strictes d'aliases"

Comment faire pour ne plus l'avoir ? Merci

Ca me parait extremement foireux comme code...

Avant toute chose, pose toi la question de savoir si tu a reellement besoin de ça.

Ensuite, met les messages d'erreur en anglais la prochaine fois, la traduction automatique c'est incomprehensible.

Et finalement, les 2 warnings correspondent aux casts, que d'ailleurs je ne comprends pas, donc j'aurais tendance a les remettre en cast normal :

i = static_cast<long>( y);

Apres, si il touche directement a l'encodage des floats, c'est vraiment hyper pourri comme bout de code.


Pour info, voici la racine carrée version speed, methode Ogre3D :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

// returns a for a * a = r float asm_sqrt( float r ) { #if OGRE_COMPILER == OGRE_COMPILER_MSVC && OGRE_ARCH_TYPE == OGRE_ARCHITECTURE_32   __asm { fld r // r0 = r fsqrt // r0 = sqrtf( r0 ) } // returns r0   #else   return sqrt( r );   #endif }

---

Comme tu peux le voir sur les #define, la partie asm n'est valable que pour Windows.

Si Ogre3D n'utilise pas de feinte sous gcc, c'est probablement parcequ'il n'y en a pas ou que ce n'est pas la peine ... ( ne sous estime pas l'implementation du sqrt de base).

Merci pour ta réponse

Pour mon compilateur, je ne sais pas pourquoi il essaye de traduire certain message en français et d'autre non !

Pour ce qui est du code pourri...c'est quand même JC qui l'a écrit (notre fameux John Carmack).
Le static_cast ne fonctionne pas : le code compile mais à l'exécution, j'ai n'importe quoi comme résultat. Et le code de Ogre ne m'intéresse guère si ce n'est que pour Windows :(

Une idée ?!

Salut,

L'avertissement te signale que la manière dont tu fais ta conversion est pour le moins dangeureuse:

Voyons le raisonnement par étape pour essayer de te faire comprendre pourquoi le compilateur rechigne

1. &y ==> demande l'adresse à laquelle se trouve y (un réel) (on va appeler le résultat A)
2. (long*) A ==> signale que l'on veut considérer A comme l'adresse à laquelle se trouve un entier (appelons le résultat B)
3. * B==> demande la valeur contenue à l'adresse B (appelons le résultat C)
4. i= C assigne la valeur (de type long) de C à i

On peut comprendre que ce genre de comportement soit de nature à éveiller les crainte du compilateur :D

Citation:

---

Envoyé par casafa

Pour ce qui est du code pourri...c'est quand même JC qui l'a écrit (notre fameux John Carmack).

---

Ok, si c'est une approximation, ça explique pas mal de choses ^^.
Notemment pourquoi j'ai rien compris, et pourquoi Ogre l'utilise pas.

Citation:

---

Le static_cast ne fonctionne pas : le code compile mais à l'exécution, j'ai n'importe quoi comme résultat. Et le code de Ogre ne m'intéresse guère si ce n'est que pour Windows :(

Une idée ?!

---

Vi :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

float SquareRootFloat(float number) { long *i; float x, y; const float f = 1.5F;   x = number * 0.5F; y = number; i = reinterpret_cast<long*>( &y); * i = 0x5f3759df - ( *i >> 1 ); float * l_tempY = reinterpret_cast<float *>(i) ; y = *l_tempY; y = y * ( f - ( x * y * y ) ); y = y * ( f - ( x * y * y ) ); return number * y; }

---

Ca marche chez moi, et ça me sort pas de warning, et ça donne le bon resultat pour un sqrt ( 2 ).

Par contre, savoir si c'est rellement plus rapide.... Le sqrt de base de Quake3 date d'y a quoi, 9 ans ? La version actuelle est probablement plus rapide.
A tester ?

Citation:

---

Envoyé par Kujara

<snip>

Par contre, savoir si c'est rellement plus rapide.... Le sqrt de base de Quake3 date d'y a quoi, 9 ans ? La version actuelle est probablement plus rapide.
A tester ?

---

Pas forcément...

Bien sur, tu verra une différence de temps entre le temps de calcul d'une racine carrée sur une machine de 9 ans et le temps de calcul d'une racine carrée sur une machine actuelle...

Mais la différence sera uniquement due à la rapidité avec laquelle le processeur va effectuer les différentes instructions...

On a très vite fait le tour des algorithmes possibles pour calculer la racine carrée d'un nombre (je ne suis même pas sur qu'il en existe beaucoup plus de deux)...

Alors, *peut être* y a-t-il un algorithme plus efficace qu'un autre, et *peut-être* peut-on trouver une implémentation de cet algorithme qui fera encore gagner quelque fréquences d'horloge...

Mais, l'un dans l'autre, il y a fort à parier que l'algorithme utilisé du temps de Quake 3 pour calculer la racine carrée soit encore exactement celui qui est utilisé actuellement... Et même que le code fourni ici soit... une implémentation "perso" de cet algorithme ;)

Kujara: Attention, ces deux expressions ont des valeurs totalements différentes:

• static_cast< long >(unDouble) retourne la partie entière (J'oublie toujours quelles sont les règles d'arrondi dans ce cas-là, et dans ce post je m'en moque).
• *reinterpret_cast< long const * >(&unDouble) donne la valeur servant à coder le flottant, valeur dépendant du type de codage. Pour des flottants IEEE, on peut prévoir à quoi ça correspond..

Citation:

---

Envoyé par Médinoc

Kujara: Attention, ces deux expressions ont des valeurs totalements différentes:

• static_cast< long >(unDouble) retourne la partie entière (J'oublie toujours quelles sont les règles d'arrondi dans ce cas-là, et dans ce post je m'en moque).
• *reinterpret_cast< long const * >(&unDouble) donne la valeur servant à coder le flottant, valeur dépendant du type de codage. Pour des flottants IEEE, on peut prévoir à quoi ça correspond..

---

Je sais, le static_cast etait une erreur de ma part ( j'avais pas compris le bout de code quand j'en ai parlé).

Le reinterpret cast marche très bien et fait ce qu'on lui demande, c'est a dire interpreter la zone mémoire pointée comme etant d'un autre type.

Citation:

---

J'oublie toujours quelles sont les règles d'arrondi dans ce cas-là, et dans ce post je m'en moque

---

Arrondi inferieur pour autant que je me souvienne.

Merci pour vos réponses