Cosinus en c

Version imprimable

Cosinus en c

Bonjour,
Je réalise un programme pour calculer la trajectoire d'une bille. Jusqu'ici le programme marche parfaitement, mais quand j'intègre les cosinus et les tangentes au calcul de l'ordonnée de la bille, la fenetre ce referme immédiatement et renvoie 3... Y a-t-il quelque chose de spécial a faire pour la trigo?

Voici mes déclarations des variables de calcul et mon code d'affichage du point.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
int continuer = 1, continuerD = 1, sourisX, sourisY, tempsActuel = 0, tempsPrecedent = 0, tempsDepart = 0, X = 12, Y = 472;
 
double distance, gravite = 9.81, vitesse = sqrt(3*9.81), angle = 0, angleRad = 0, Sin2Teta = 0, Teta2 = 0 ,Z = 472, A = 12;
 
               if(event.button.x >= 745 && event.button.y >= 510 && event.button.x <= 793 && event.button.y <= 558)
                {
                    tempsDepart = SDL_GetTicks();
                    while(tempsActuel - tempsDepart < 10000)
                    {
                        tempsActuel = SDL_GetTicks();
                        if (tempsActuel - tempsPrecedent > 100)
                        {
                            Sin2Teta=(distance*gravite)/(vitesse*vitesse);
                            Teta2=asin(Sin2Teta);
                            angleRad=Teta2/2;
                            angle = (180*angleRad)/M_PI;
                            X++;
                            Z =  Z - ( - gravite / (2 * pow(vitesse, 2) * pow(cos(angleRad), 2)) * X * X + tan(angleRad) * X);
                            Y = (int)Z;
 
                            positionBille.x = X;
                            positionBille.y = Y;
                            tempsPrecedent = tempsActuel;
                            SDL_BlitSurface(bille, NULL, ecran, &positionBille);
                            SDL_Flip(ecran);
                        }
                    }
                }

23/01/2012, 08h57
Sve@r

Salut
Tu devrais rajouter du printf() pour être sûr que ça vient bien de ces fonctions. Et aussi pour vérifier si le dénominateur de ta division ne vaut pas 0. Et j'espère aussi que tu as inclus <math.h>...
24/01/2012, 06h56
Neckara

Pour utiliser les fonctions cosinus, tangente et sinus, on nous conseille de ne pas utiliser ces fonctions.

Mais plutôt de créer un tableau puis de lire dedans cosinus[x] pour cos(x), ce qui est d'après mes sources plus rapide.

Sinon, return 3, c'est un SEGFAULT, tu touches un espace mémoire qui ne t'appartient pas.

Dans le cas d'une division par 0, c'est un autre type d'erreur.

Essaye surtout de regarder au niveau de tes pointeurs
24/01/2012, 09h06
LittleWhite

Bonjour,

Citation:

Mais plutôt de créer un tableau puis de lire dedans cosinus[x] pour cos(x), ce qui est d'après mes sources plus rapide.

, oui, sur Amiga ou les consoles portables qui n'ont pas de gestion de virgule flottante. Mais en général, maintenant, les PCs sont capable de répondre en un temps appréciable aux fonctions cos() / sin() (même s'il est vrai que le précalcul sera toujours plus rapide).
24/01/2012, 23h08
Sve@r

Citation:

Envoyé par Neckara

Mais plutôt de créer un tableau puis de lire dedans cosinus[x] pour cos(x), ce qui est d'après mes sources plus rapide.

Pas évident car comment affuter ce tableau ? De 1 en 1 ? De 0.1 en 0.1 ?? De 0.01 en 0.01 ???
25/01/2012, 06h57
Neckara

C'est à lui de le déterminer en fonction de son utilisation.

Après comme cela je ne peux évidemment pas donner de chiffres.

Vu que pour la gravité, il prend 9,81 je dirais qu'il devrait affuter de 0,001 en 0,001 (comme ça il est sûr d'avoir une précision qui lui convienne mais de 0,01 en 0,01 pourrait marcher aussi)
26/01/2012, 23h03
anacharsis

salut !
le cosinus ne peut pas engendrer d'erreur ! par contre la tangente, l'arc sinus oui.

A+
03/02/2012, 11h09
screetch

c'est n'importe quoi le cosinus en table qui va plus vite que la fonction cos()

il y a 25 ans les processeurs etaient lent, stocker les résultats en mémoire ca valait le coup
depuis les processeurs sont environ 1 000 000 fois plus rapides alors que la mémoire est 1000 fois plus rapide, le processeur mange du cosinus d'arctangeante au petit dej.

au pire pour des résultats locaux, si tu dois calculer des cosinus pour 5/6 valeurs et les reutiliser, tu fais un cache local.
03/02/2012, 11h37
diogene

Pas d'accord sur cette remarque : Je pense qu'un accès à un tableau reste plus rapide que le calcul d'un cosinus. L'intérêt dépend du nombre de cosinus à calculer dans le programme. Si on en a une centaine, peu importe mais pour 1 ou 10 milliards ... Il faut s'adapter à chaque cas particulier.

Le fait que les processeurs sont 1 000 000 de fois plus rapide qu'avant n'est pas un argument sur le fait qu'on peut négliger les temps de calcul; on demande maintenant à ces processeurs de faire 1 000 000 de fois plus de choses qu'avant.
03/02/2012, 12h13
screetch

tu penses ou tu es sur?
moi je suis sur que non
la mémoire marche de maniere tres compliquée (et un processeur aussi) et les accès mémoire sont la cause numéro 1 des ralentissements. A cause des latences, des caches, de la coherence...
a coté de ca maintenant, calculer un cosinus c'est fait sur la FPU ou sur le SSE et ca prend rien comme temps.

Alors si tu veux faire du code cradoc et foutre en l'air une ligne de cache a chaque fois que tu veux un cosinus, libre a toi; tu vas te retrouver avec deux "cache miss" (un pour le cosinus et un pour celui qui se servait de ce cache) qui sont très lent et comme tu accèdes a la mémoire, tu risques de foutre en l'air des optims du processeur.

Les solutions les plus simples sont parfois les meilleures hein.
03/02/2012, 13h05
Neckara

Il y a deux méthodes :

Le calcul ou le pré-calcul.
On ne peut pas dire que l'un d'entre eux est inutile sans connaître l'utilisation qu'on fera de ces valeurs ainsi que les moyens techniques du client.

Je ne suis pas super-calé dans ce domaine, je ne faisais que dire que j'ai déjà vu qu'on conseillait plutôt un pré-calcul mais mes sources peuvent dater, je l'admet.

Ensuite tu parles d'accès mémoire, mais de quelle mémoire parles-tu?
Mémoire Vive? Mémoire Morte?

Que je sache, une fois le cosinus calculé, il va mettre le résultat dans la mémoire vive.
Avec le pré-calcul, le résultat est en mémoire vive dès le chargement.
Bien sûr, on peut décider de calculer les valeurs des cosinus dès le début du lancement pour avoir du pré-calcul par la suite

Mais on ne peut pas juger de la meilleur méthode sans savoir l'utilisation qu'on va en faire.
03/02/2012, 13h22
valefor

Citation:

Envoyé par Neckara

Mémoire Vive? Mémoire Morte?

La mémoire vive est certes une mémoire "rapide". Mais à l'échelle du processeur, encore un peut lente. Le processeur dispose donc à "côté de lui" de mémoires tampon (caches), et enfin de registres.
Sans parler du cas extrême où tu demandes une zone mémoire qui a été mise de côté (en mémoire morte selon tes termes) par l'os.

Une donnée que tu crois en "mémoire vive" peut donc passer de la "mémoire morte" au cache puis atteindre enfin un registre avant d'être utilisée. Ce voyage prend un certain temps (variable selon si la donnée est déjà ou pas dans le registre/cache/mémoire, et selon si elle peut être modifiée par ailleurs que par le proc, et j'en oublie certainement d'autre)

screetch parle de ce genre de temps je pense.

J'oubliais aussi un truc, si on utilise des flottants pour représenter les nombres, l'index du tableau devra quand même être un entier, donc il faudra transformer un flottant en entier. Et c'est une instruction de plus.
03/02/2012, 13h36
screetch

Certes si tout tient dans le cache, si aucune autre utilisation n'est faite de la mémoire alors ca peut valoir le coup (?) de faire ca.
Dans n'importe quel programme ca serait un coût plus qu'un gain, a moins de faire du batch de cosinus a longueur de programme.
03/02/2012, 14h11
souviron34

dans ce débat la question est surtout

Citation:

Envoyé par Neckara

Pour utiliser les fonctions cosinus, tangente et sinus, on nous conseille de ne pas utiliser ces fonctions.

Qui te conseille ça et pourquoi ?

Dans 99.999999999% des cas aujourdhui cela n'a pas d'influence...

Franchement j'aimerais bien connaître les raisons et le contexte d'un tel conseil !!! :calim2:
03/02/2012, 15h25
anacharsis

urban legend

Citation:

on nous conseille de ne pas utiliser ces fonctions.

les légendes ont la vie dure ...

A+
05/02/2012, 10h52
dba01

J'avais fait un truc comme ça en Basic il y a plus de 20 ans, car je n'avais pas les fonctions trigo dans ma machine.
J'ai retrouvé un vieux texte dans mes archives. Mais je ne sais plus si c'était un brouillon ou un truc en état de marche. D'ailleurs, j'ai deux définitions du COS, et il me semble me rappeler que l'ATN fonctionnait une fois sur deux.

Donc c'est à revérifier et réécrire.

Pi.......................................3.1415926535897932384626433
COS(radians)........................SIN(radians + (Pi / 2) )
TAN(radians)........................SIN(radians) / COS(radians)
COT(radians)........................1 / TAN(radians)

____

function FACTOR(INIFACT) // Factorielle(nombre)

RESUFACT := INIFACT
for BASFACT = (INIFACT-1) to 1 step -1
RESUFACT *= BASFACT
next

return RESUFACT

function SIN(INISINUS) // Sinus(radians)

IN2SINUS := INISINUS % (2 * Pi)
RESUSINUS := IN2SINUS
RESUSINUS -= ( IN2SINUS **3 ) / FACTOR(3 )
RESUSINUS += ( IN2SINUS **5 ) / FACTOR(5 )
RESUSINUS -= ( IN2SINUS **7 ) / FACTOR(7 )
RESUSINUS += ( IN2SINUS **9 ) / FACTOR(9 )
RESUSINUS -= ( IN2SINUS **11) / FACTOR(11)
RESUSINUS += ( IN2SINUS **13) / FACTOR(13)
RESUSINUS -= ( IN2SINUS **15) / FACTOR(15)
RESUSINUS += ( IN2SINUS **17) / FACTOR(17)
RESUSINUS -= ( IN2SINUS **19) / FACTOR(19)

return RESUSINUS

function COS(INICOSIN)

IN2SINUS := INICOSIN % (2 * Pi)
RESUSINUS := 1
RESUSINUS -= ( IN2SINUS **2 ) / FACTOR(2 )
RESUSINUS += ( IN2SINUS **4 ) / FACTOR(4 )
RESUSINUS -= ( IN2SINUS **6 ) / FACTOR(6 )
RESUSINUS += ( IN2SINUS **8 ) / FACTOR(8 )
RESUSINUS -= ( IN2SINUS **10) / FACTOR(10)
RESUSINUS += ( IN2SINUS **12) / FACTOR(12)
RESUSINUS -= ( IN2SINUS **14) / FACTOR(14)
RESUSINUS += ( IN2SINUS **16) / FACTOR(16)
RESUSINUS -= ( IN2SINUS **18) / FACTOR(18)

return RESUSINUS

function ATN(INIARCTN) // ArcTAN(tang) => rad

if INIARCTN < 10 .and. INIARCTN > -10
RESUARCTN := Pi * 1.5
TPNARCTN := RESUARCTN / 20
do while abs(TAN(RESUARCTN) - INIARCTN) > 0.00001
do while TAN(RESUARCTN) > INIARCTN
RESUARCTN -= TPNARCTN
enddo
do while TAN(RESUARCTN) < INIARCTN
RESUARCTN += TPNARCTN
enddo
TPNARCTN *= 0.1
enddo
elseif INIARCTN < -10000
RESUARCTN := (2 * Pi * 90.02 / 360)
elseif INIARCTN < -1000
RESUARCTN := (2 * Pi * 90.3 / 360)
elseif INIARCTN < -100
RESUARCTN := (2 * Pi * 92 / 360)
elseif INIARCTN < 100
RESUARCTN := (2 * Pi * 88 / 360)
elseif INIARCTN < 1000
RESUARCTN := (2 * Pi * 89.7 / 360)
else
RESUARCTN := (2 * Pi * 89.98 / 360)
endif
// if RESUARCTN > Pi ; RESUARCTN -= Pi ; endif

return (RESUARCTN - Pi)

PS : et en plus je n'ai jamais été un as en maths !
05/02/2012, 13h22
anacharsis

salut !

je viens aussi de cette époque ;=)
le basic utilisé était assez extraordinaire (je pense desassemblé du HP-65 car même bug sur les sqrt d'un float < 1e-9) ...

A+
13/02/2012, 11h28
aslo92

Citation:

c'est n'importe quoi le cosinus en table qui va plus vite que la fonction cos()

J'ai chronométré les 2 méthodes sur un PC récent (processeur i5-2400 à 3.1GHz avec 4 Go de Ram)

Voici les résultats de la lecture de 10 valeurs de cosinus avec une précision de 0.0001 rad

opération: a = cos(angle) ==> nombre de coups d'horloge cpu = 2220
opération: a = cos_t[(int)(angle * 10000)] ==> nombre de coups d'horloge cpu = 329
13/02/2012, 11h33
screetch

faudrait voir comment tu viens de foutre en l'air ton cache pour toute les opérations suivantes maintenant. Même si le cosinus lui même est plus long a calculer, si ta table de cosinus n'était pas déjà dans le cache (ce qui ne se voit pas sur un benchmark) ou si tu viens de decharger une ligne de cache qui aurait été utile deux instructions plus bas (ce qu'un benchmark ne permet pas de mesurer non plus) alors au final tu y perds.
13/02/2012, 11h44
souviron34

C'est surtout qu'avant d'en arriver à tenter d'optimiser des opératons de base, il vaudrait mieux passer son temps à optimiser l'alogorithme qui les utilise... Plus l'écriture du code...

Une fois cela fait, et si ça n'est pas encoe suffisant, on peut éventuellement penser à se compliquer la vie..

Mais c'est tout à fait inutile dans 99.999999999999 % des cas...
13/02/2012, 12h39
aslo92

Citation:

faudrait voir comment tu viens de foutre en l'air ton cache pour toute les opérations suivantes maintenant. Même si le cosinus lui même est plus long a calculer, si ta table de cosinus n'était pas déjà dans le cache (ce qui ne se voit pas sur un benchmark) ou si tu viens de decharger une ligne de cache qui aurait été utile deux instructions plus bas (ce qu'un benchmark ne permet pas de mesurer non plus) alors au final tu y perds.

Pour prouver ce que tu avances, il faudrait utiliser VTUNE sur le code à optimiser.

Tout dépend de la précision dont tu as besoin pour ton calcul. Si tu as besoin de 10 décimales, je suis d'accord avec toi, c'est pas jouable car le tableau de cosinus sera trop gros.

Par contre si 2 décimales suffisent ton tableau de cosinus occupera 315*8=2520 octets ce qui est suffisamment petit pour ne pas perturber des données présentes même dans le cache L1.
13/02/2012, 13h22
souviron34

Citation:

Envoyé par aslo92

Par contre si 2 décimales suffisent ton tableau de cosinus occupera 315*8=2520 octets ce qui est suffisamment petit pour ne pas perturber des données présentes même dans le cache L1.

Voir plus haut...

Ce genre de choses n'est à faire qu'en dernier recours, lorsque TOUTES les optimisations des algorithmes et du code ont été faites..

D'après les posts, je pense que nous en sommes très très très loin, et que par conséquent ces questions n'ont pas lieu d'être...
13/02/2012, 14h20
screetch

une precision de 0.01 en entrée ne donnera pas un résultat cosinus correct a 0.01 je pense.

Citation:

Envoyé par aslo92

Pour prouver ce que tu avances, il faudrait utiliser VTUNE sur le code à optimiser.

et pourquoi il faudrait prouver ce que j'avance? pourquoi toi tu pourrais pas prouver ce que tu avances a la place? je veux dire, c'est quand même pas moi qui veut remplacer une instruction ASM par un lookup dans une table et cradoquer mon code (ou pire, le code des autres). Alors pourquoi je devrais aller justifier (malgré tout j'ai deja foutu pas mal d'explications ici) que le code devrait rester propre au lieu de saloper tout avec des cosinus imprécis et a peine plus rapides sans même savoir si il y avait un problème de ce coté?

non, TOI tu sors VTune et tu me prouves que la solution a base de tableaux elle pourrit pas son cache plutôt
13/02/2012, 14h53
Neckara

cosinus imprécis...

Dans les matières comme la physique il est inutile d'avoir 300 chiffres significatifs.
On n'utilise pas de valeurs exacte (d'ailleurs l'ordinateur ne sais pas calculé de valeur exacte mais seulement des valeur approchées).
Le tout est de savoir de combien de chiffre significatif, le degré de précision dont on a besoin.

Sinon, je ne vois pas l'utilité d'un tel débat ici.
On a vu dans les posts précédents que finalement, les processeurs s'étaient amélioré et qu'aujourd'hui, la fonction cos(x) est assez rapide.

Ensuite, entre cos(x) ou cos[x] je pense que chacun est libre de choisir.
On est pas dans le cas d'un programme à optimiser à 200%.

cos[x] prend de la place mémoire donc il ne faut pas l'utiliser pour un degré trop grand de précision.
cos(x) serait apparemment encore un petit peu moins rapide que cos[x], mais ce n'est pas significatif ici.

Après, chacun code comme il veut.
13/02/2012, 18h38
Sve@r

Citation:

Envoyé par Neckara

...d'ailleurs l'ordinateur ne sais pas calculé de valeur exacte mais seulement des valeur approchées

Salut

Attention à la façon de dire les choses. S'il est vrai que le codage des flottants (avec mantisse et exposant) n'est pas toujours exact, il existe d'autres façon de coder les décimaux. Le COBOL, par exemple, avec sa déclaration PIC 99V999 te donnera un nombre à 3 décimales en précision absolue. Le module decimal de Python te donnera lui aussi des décimaux parfaits. Et sûrement d'autres librairies dans d'autres langages font la même chose...
13/02/2012, 19h30
Neckara

Bien sûr, quand la fonction est un polynôme, l'ordinateur peut nous donner une valeur exacte.

Mais dans le cas de fonctions exponentielle, cosinus et autres, l'ordinateur passe par une formule de Taylor si je ne dit pas de bêtise.

L'ordinateur calculera donc une valeur approchée au voisinage d'un point connu.
Il peut arriver que la valeur approchée soit égale à la valeur exacte, mais ce n'est pas toujours le cas.
Au mieux il pourra donner une expression, mais c'est impossible de donner une valeur exacte d'un nombre ayant une infinité de chiffres décimaux.
13/02/2012, 22h48
anacharsis

Citation:

Mais dans le cas de fonctions exponentielle, cosinus et autres, l'ordinateur passe par une formule de Taylor si je ne dit pas de bêtise.

tu ne dis pas de bêtise ! mais l'algorithme est un peu plus compliqué : on divise l'argument par 2 jusqu'à obtenir un argument assez petit (pour que Taylor soit assez précis), puis on utilise Taylor sur ce petit argument, puis un opérateur de différences finies (sur des polynômes de degré 2) pour évaluer la fonction du double du petit argument et on répète jusqu'à retrouver l'argument initial (en fait on compte les étapes de division par 2, et on applique autant d'étapes dans la multiplication par 2 sans évaluer l'argument).
les publications faites autour des calculatrices HP-65 des années 74-75 donnaient pas mal de détails sur ces questions, et bien que, depuis, les processeurs soient passés de 4 bits à 64 bits, les algorithmes n'ont pas beaucoup changé.
PS pour ceux qui sont réellement au fait de ces algorithmes, je sais que la réalité est un peu plus compliquée, puisque les coefficients de Taylor sont pré-calculés et sont parfois pris en compte dans l'opérateur de différences finies.

A+
14/02/2012, 01h11
souviron34

ce qui fait que je doute extrêmement fortement de la mesure donnée en fin de première page qu'il faudrait 220 opérations/cycles pour calculer un cosinus..

Citation:

c'est quand même pas moi qui veut remplacer une instruction ASM par un lookup dans une table

Je ne vois pas très bien quelle est l'instruction ASM magique dont on parle. Si c'est FCOS, ça fait bien longtemps que ça n'est plus utilisé.
En traçant le code de cos(x) on obtient ça:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
73B2E7B8  movlpd      xmm0,qword ptr [esp+4]  
73B2E7BE  pextrw      eax,xmm0,3  
73B2E7C3  and         ax,7FFFh  
73B2E7C7  sub         ax,3030h  
73B2E7CB  cmp         ax,10C5h  
73B2E7CF  ja          73B2E917  
73B2E7D5  movlpd      xmm1,qword ptr ds:[73B2F190h]  
73B2E7DD  mulsd       xmm1,xmm0  
73B2E7E1  movlpd      xmm2,qword ptr ds:[73B2F198h]  
73B2E7E9  cvtsd2si    edx,xmm1  
73B2E7ED  addsd       xmm1,xmm2  
73B2E7F1  movlpd      xmm3,qword ptr ds:[73B2F1B0h]  
73B2E7F9  subsd       xmm1,xmm2  
73B2E7FD  movapd      xmm2,xmmword ptr ds:[73B2F1A0h]  
73B2E805  mulsd       xmm3,xmm1  
73B2E809  unpcklpd    xmm1,xmm1  
73B2E80D  add         edx,1C7610h  
73B2E813  movsd       xmm4,xmm0  
73B2E817  and         edx,3Fh  
73B2E81A  movapd      xmm5,xmmword ptr ds:[73B2F180h]  
73B2E822  lea         eax,ds:[73B2E950h]  
73B2E828  shl         edx,5  
73B2E82B  add         eax,edx  
73B2E82D  mulpd       xmm2,xmm1  
73B2E831  subsd       xmm0,xmm3  
73B2E835  mulsd       xmm1,mmword ptr ds:[73B2F1B8h]  
73B2E83D  subsd       xmm4,xmm3  
73B2E841  movlpd      xmm7,qword ptr [eax+8]  
73B2E846  unpcklpd    xmm0,xmm0  
73B2E84A  movsd       xmm3,xmm4  
73B2E84E  subsd       xmm4,xmm2  
73B2E852  mulpd       xmm5,xmm0  
73B2E856  subpd       xmm0,xmm2  
73B2E85A  movapd      xmm6,xmmword ptr ds:[73B2F160h]  
73B2E862  mulsd       xmm7,xmm4  
73B2E866  subsd       xmm3,xmm4  
73B2E86A  mulpd       xmm5,xmm0  
73B2E86E  mulpd       xmm0,xmm0  
73B2E872  subsd       xmm3,xmm2  
73B2E876  movapd      xmm2,xmmword ptr [eax]  
73B2E87A  subsd       xmm1,xmm3  
73B2E87E  movlpd      xmm3,qword ptr [eax+18h]  
73B2E883  addsd       xmm2,xmm3  
73B2E887  subsd       xmm7,xmm2  
73B2E88B  mulsd       xmm2,xmm4  
73B2E88F  mulpd       xmm6,xmm0  
73B2E893  mulsd       xmm3,xmm4  
73B2E897  mulpd       xmm2,xmm0  
73B2E89B  mulpd       xmm0,xmm0  
73B2E89F  addpd       xmm5,xmmword ptr ds:[73B2F170h]  
73B2E8A7  mulsd       xmm4,mmword ptr [eax]  
73B2E8AB  addpd       xmm6,xmmword ptr ds:[73B2F150h]  
73B2E8B3  mulpd       xmm5,xmm0  
73B2E8B7  movsd       xmm0,xmm3  
73B2E8BB  addsd       xmm3,mmword ptr [eax+8]  
73B2E8C0  mulsd       xmm1,xmm7  
73B2E8C4  movsd       xmm7,xmm4  
73B2E8C8  addsd       xmm4,xmm3  
73B2E8CC  addpd       xmm6,xmm5  
73B2E8D0  movlpd      xmm5,qword ptr [eax+8]  
73B2E8D5  subsd       xmm5,xmm3  
73B2E8D9  subsd       xmm3,xmm4  
73B2E8DD  addsd       xmm1,mmword ptr [eax+10h]  
73B2E8E2  mulpd       xmm6,xmm2  
73B2E8E6  addsd       xmm5,xmm0  
73B2E8EA  addsd       xmm3,xmm7  
73B2E8EE  addsd       xmm1,xmm5  
73B2E8F2  addsd       xmm1,xmm3  
73B2E8F6  addsd       xmm1,xmm6  
73B2E8FA  unpckhpd    xmm6,xmm6  
73B2E8FE  addsd       xmm1,xmm6  
73B2E902  sub         esp,10h  
73B2E905  addsd       xmm4,xmm1  
73B2E909  movlpd      qword ptr [esp+4],xmm4  
73B2E90F  fld         qword ptr [esp+4]  
73B2E913  add         esp,10h  
73B2E916  ret

On est bien loin d'une instruction assembleur qui fait le travail en un claquement de doigt... C'est peut-être la formule de Taylor dont parle Neckara ?

Pour info, voici le code généré pour lire la valeur du cosinus dans une table:

Code:

1
2
0125143E  mov         eax,dword ptr [t_cos]  
01251441  fld         qword ptr [eax+2F98h]

On se demande bien pourquoi c'est plus rapide non ?

Citation:

Alors pourquoi je devrais aller justifier (malgré tout j'ai deja foutu pas mal d'explications ici) que le code devrait rester propre au lieu de saloper tout avec des cosinus imprécis et a peine plus rapides

Est-ce que le code est moins lisible en faisant: a = t_cos[x] au lieu de a = cos(x) ? J'avoue que là, j'ai un peu de mal à comprendre !

Concernant le fait que ce soit à peine plus rapide, je pense qu'un facteur 5 est loin d'être à peine plus rapide. C'est comme si je vendais une 2CV au prix d'une Ferrari à peine plus rapide (facteur 3).

14/02/2012, 01h31
souviron34

'fin, tu fais comme tu veux, hein...

C'est juste que, comme dit plus haut, ça n'a aucun intérêt dans 99.9999999999999% des cas...

Alors, tu fais comme tu veux, hein.. Tu peux chercher à réinventer toutes les fonctions et de maths, et diverses et variées.. Je suis certain que tu peux même refaire un système d'exploitation... :)

Mais je suis certain que si je te vois arriver demander un boulot, je ne prend pas dans mon équipe ;)

Et que je n'ai pas envie d'avoir à reprendre un code que tu aurais fait..
14/02/2012, 02h22
anacharsis

@Ouranis

comme tu peux le constater, le débat devient un peu houleux. il est grand temps de le clore car : tu veux calculer une position toutes les 100 millisecondes et ce, pendant 10 secondes. d'où pour toi, environ 100 calculs.

pour obtenir un cosinus par lecture d'une table, avec une précision de 2 chiffres après la virgule il te faudra une table d'un peu plus de 150 valeurs (tu peux le vérifier avec n'importe quel tableur). pour la remplir, il te faudra donc calculer 150 cosinus et ensuite en lire 100.

si tu trouves ça très à ton goût, fais le !
14/02/2012, 09h47
Bktero

J'ai lu de ces trucs dans ce sujet :calim2:

Sans vous vexez, j'ai vu un benchmark fait avec 10 calculs et une seule configuration, quelqu'un dire que ce n'est pas à lui de prouver que ça perturbe le cache alors que son contradicteur a essayé de faire une démonstration, j'ai appris qu'on n'utilisait pas les valeurs exactes et que l'ordinateur n'en calculait pas.... mais quand on utilise pi comment avoir des valeurs exactes ? Enfin, concernant le gain en cycle CPU, je dirais que quand j'ai une mémoire flash de quelques ko pour stocker mon programme, je vais vraiment réfléchir au gain en vitesse contre la perte de mémoire à stocker mes cosinus dans un tableau.

Une personne ici a tellement raison, c'est souviron34 ! Il y a tellement d'optimisations à faire dans nos algorithmes et nos codes (les miens les premiers !) pour ne se préoccuper du cosinus qu'en dernier recours :D
14/02/2012, 09h53
aslo92

Je suis désolé si j'ai froissé certaines personnes. Ce n'était pas le but !
J'ai peut-être trop fait de temps réel et ce n'est apparemment pas le but à atteindre dans cette discussion ?

Bonne journée à tous
14/02/2012, 10h27
Bktero

En fait le but du message original ne parle absolument pas d'optimisation du calcul du cosinus, on s'est juste lancé dans un long débat à cause de Neckara ( :sm: )

Si tu as une vision temps réel, dans ce cas je comprends mieux ton raisonnement. Pour toi, gagner des cycles CPU pour que ta tâche se termine dans les temps est important. Je pense que ta remarque et celle de souviron se rejoignent d'une certaine façon : en règle générale, ce n'est pas utile car il y beaucoup d'optimisations à faire avant celle-là ; dans certains cas, on a besoin des dernières optimisations pour répondre à certaines contraintes.
14/02/2012, 18h52
souviron34

Citation:

Envoyé par aslo92

Je suis désolé si j'ai froissé certaines personnes. Ce n'était pas le but !
J'ai peut-être trop fait de temps réel et ce n'est apparemment pas le but à atteindre dans cette discussion ?

Bonne journée à tous

Désolé que tu l'aies pris comme ça : tu n'as froissé personne (enfin, je pense) ici..

Ce qu'on en dit, c'est que c'est peu important en général.

J'ai par contre trouvé un lien qui peut t'intéresser :

How does C computes sin and other math functions, où, de manière générale, il est dt que cela dépend à 100% des implémentations et de la bibliothèque et du compilateur, avec appel éventuel aux fonctions du processeur (et donc très nettement plus rapides que tout algo),, et vers le bas de la page, tu trouveras aussi une autre méthode rapide..

:)