Discussion :

[casafa]

Bonjour,

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

Code :

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

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

[Kujara]

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 :

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

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).

[casafa]

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 ?!

[Kujara]

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.

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 :

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

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 ?

[koala01]

<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

[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..

[Kujara]

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.

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.

[koala01]

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