calculer la distance entre 2 points [Math] - Programmation
Marsh Posté le 24-02-2002 à 11:09:52
Soit un point P1 (x1, y1) et un point P2(x2, y2):
distance entre P1 et P2 = sqrt( (x2 - x1)^2 + (y2 - y1)^2 )
Voilà, ça marche pour toutes les dimensions, suffit de rajouter de façon analogue les autres coordonnées.
Marsh Posté le 24-02-2002 à 15:10:19
c pythagore ca
Marsh Posté le 24-02-2002 à 15:13:07
deathsharp a écrit a écrit : c pythagore ca |
oui, c'est pythagore, on peut tjs considérer que 2 points sont en fait 2 sommets d'un triangle rectangle dans un plan. Connaissant les coordonnées des 2 points, c facile.
Marsh Posté le 24-02-2002 à 16:04:37
c la distance euclidienne .
et x^2 n'existe pas en §C je crois , il faut utiliser pow(x,2)
voila
Marsh Posté le 24-02-2002 à 21:31:47
Euh, pour x^2 aussi appelé pow(x,2), il serait pas plus malin de faire x*x ? Non perso, je pense pas que pow(x, 2) soit plus rapide que simplement x*x
Marsh Posté le 24-02-2002 à 23:52:20
x*x est toujours plus rapide que pow(x,2)
(ca doit etre le cas pour x*x*x aussi).
pow permet d'obtenir une puissance arbitraire
donc des trucs genre x puissance 1.43
A+
LEGREG
Marsh Posté le 24-02-2002 à 23:53:12
Même avis. Ou alors une petite macro ou une fonction inline en C++ et basta!
Marsh Posté le 25-02-2002 à 00:03:04
Pour le plaisir,
autres tricks classiques :
pour normaliser un vecteur
on ne fait pas
x = x/norme;
y = y/norme;
z = z/norme;
mais
inv = 1.0 / norme;
x = x * inv;
y = y * inv;
z = z * inv;
deux divisions en une seule:
x = a/b; y = c/d;
devient
inv = 1.0 / (b*d);
x = a * d * inv;
y = c * b * inv;
Modulo une puissance de deux (n = 2 ^ k) et x >= 0;
remplacer x = x % n;
par x = x & (n-1); //(and logique)
On ne compare pas un float a 0 mais on teste
le bit de signe.
Etc..
A+
LEGREG
Marsh Posté le 25-02-2002 à 00:09:31
legreg a écrit a écrit : Pour le plaisir, autres tricks classiques : pour normaliser un vecteur on ne fait pas x = x/norme; y = y/norme; z = z/norme; mais inv = 1.0 / norme; x = x * inv; y = y * inv; z = z * inv; deux divisions en une seule: x = a/b; y = c/d; devient inv = 1.0 / (b*d); x = a * d * inv; y = c * b * inv; Modulo une puissance de deux (n = 2 ^ k) et x >= 0; remplacer x = x % n; par x = x & (n-1); //(and logique) On ne compare pas un float a 0 mais on teste le bit de signe. Etc.. A+ LEGREG |
j'aime bien ce genre d'optimisation
dans le même genre, on ne teste pas sqrt(x) < y mais x < y*y
etc etc etc
Marsh Posté le 25-02-2002 à 00:15:55
Z'avez pas un site qui recense ce genre de petites astuces?
Marsh Posté le 25-02-2002 à 00:34:40
Krueger a écrit a écrit : Z'avez pas un site qui recense ce genre de petites astuces? |
Bof, il s'agit surtout de réfléchir.
Et la moitié des optimisations citées plus haut sont suffisamment triviales pour être effectuées par le compilateur.
Marsh Posté le 25-02-2002 à 00:35:39
http://www.flipcode.com/
http://www.stereopsis.com/
http://www.codercorner.com/Pierre.htm
attention tout de meme a ne pas
devenir obsede du petit cycle qui t'echappe
parce que la recherche d'optimisations
peut prendre plus de temps
que le developpement de nouvelles features
et que plus de temps tu passes sur ton
projet plus les optimisations perdent
de leur sens (exemple ceux qui ont
suroptimise leur moteur de rendu software
quand les cartes 3D ont fait leur apparition,
ca a fait pas mal de code qui a valse a la
poubelle).
mais bon le coup de x*x c'est un truc
qui sera vrai tout le temps donc il faut
juste ne pas prendre de mauvaises habitudes.
quelques regles claires:
- les divisions, modulo etc.. sont couteuses.
- Enlever tous les calculs redondants
de la boucle principale
Une derniere: parfois des idees preconcues
sur l'optimisation se revelent fausses et
seul le profiling permet de distinguer
les solutions qui permettent un gain en performance
et parfois revelent des effets contradictoires.
A+
LEGREG
Marsh Posté le 25-02-2002 à 00:38:25
Jar Jar a écrit a écrit : Bof, il s'agit surtout de réfléchir. Et la moitié des optimisations citées plus haut sont suffisamment triviales pour être effectuées par le compilateur. |
ton compilateur il remplace
de lui-meme deux divisions
par une division et 5 multiplications
en instanciant une variable intermediaire?
A+
LEGREG
Marsh Posté le 25-02-2002 à 00:53:07
Il faudrait faire des essais, mais ça ne m'étonnerait guère. En plus de ça, les processeurs actuels doivent être capables de voir qu'on leur fait faire 3 fois la même division.
Marsh Posté le 25-02-2002 à 01:03:50
je crois que tu pretes trop d'intelligence
au compilateur, il est capable
de faire des optimisations "locales" et "systematiques"
sur la strategie d'allocation des registres,
sur le deroulement des boucles et
sur l'inlining des fonctions
mais pour ce qui est des optimisations
"logiques", c'est a dire corriger
un programme mal pense, ou degrader
la precision (ce qu'aucun programmeur
au monde ne voudrait que son compilateur
fasse dans son dos mais que certains
programmeurs font parce qu'ils pensent
savoir ce qu'ils font), je ne suis
pas vraiment sur.
Par exemple: un processeur fera
toutes ses operations en double precision
et passer par une variable intermediaire
en simple precision peut donc causer
des erreurs d'arrondis supplementaires.
Un programmeur sait quand ces erreurs
d'arrondis sont acceptables, mais on demandera
au compilateur de ne pas faire de choix pour nous.
Un des auteurs de DirectX disait:
"jamais l'API ne fera des verifications
que le programmeur peut faire parce qu'elle
est concue pour la performance et
qu'elle part du principe que le programmeur
sait bien mieux que l'API ce que fait
son programme".
A+
LEGREG
Marsh Posté le 25-02-2002 à 01:11:54
sinon le trick sur la division
n'est pas de moi bien evidemment
mais de ce monsieur :
http://www.stereopsis.com/
qui est paye tres cher par des boites pour
faire les routines de "traitement d'images" les plus rapides
et je crois qu'il connait le fonctionnement
de son compilateur..
(alors que moi je fais souvent
du code non optimise, mais j'apprends
et je me consacre plutot aux features
qu'a la division rapide.)
A+
LEGREG
Marsh Posté le 25-02-2002 à 01:22:47
legreg a écrit a écrit : (alors que moi je fais souvent du code non optimise, mais j'apprends et je me consacre plutot aux features qu'a la division rapide.) |
Alors là, je suis 100 % d'accord. Vu la puissance des bécanes actuelles, on n'est pas à trois cycles près, et si en plus on perd 6 mois pour gagner 3 bugs par ligne, l'utilité de l'optimisation est assez douteuse.
Marsh Posté le 25-02-2002 à 04:10:49
Jar Jar a écrit a écrit : Alors là, je suis 100 % d'accord. Vu la puissance des bécanes actuelles, on n'est pas à trois cycles près, et si en plus on perd 6 mois pour gagner 3 bugs par ligne, l'utilité de l'optimisation est assez douteuse. |
Et on se retrouve avec un jeu 3D avec des graphiques de merde qui roule à 30 image par seconde quand un autre optimiser en fait 30 aussi mais qui est beaucoup plus beau visuellement
Marsh Posté le 25-02-2002 à 11:00:05
Jar Jar a écrit a écrit : Alors là, je suis 100 % d'accord. Vu la puissance des bécanes actuelles, on n'est pas à trois cycles près, et si en plus on perd 6 mois pour gagner 3 bugs par ligne, l'utilité de l'optimisation est assez douteuse. |
http://cycojesus.free.fr/progs/openglavity/index.htm
=> 10 fps gagnée rien qu'en modifiant la boucle principale,
presque autant en remplaçant une fonction par un #define
l'optimisation C'EST BIEN !!
[jfdsdjhfuetppo]--Message édité par cycojesus--[/jfdsdjhfuetppo]
Marsh Posté le 25-02-2002 à 13:18:05
cycojesus a écrit a écrit : l'optimisation C'EST BIEN !! |
Oui, mais ce n'est pas si simple. L'optimisation, c'est surtout repérer les portions de code qui mettent le plus de temps à s'exécuter. Tu peux multiplier par 10 la vitesse d'une portion de code sans que ça se voie dans le résultat final.
Marsh Posté le 24-02-2002 à 11:04:57
c'est koi encore la formule?