fcos de asm plus rapide?

Version imprimable

Bonjour, suite au code fournie par flyweight
http://www.developpez.net/forums/sho...55&postcount=8
j'ai testé avec GCC pour voir les différences de performance... ET le cos de asm est plus rapide 8O

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
 
#include <iostream>
#include <cmath>
#include <ctime>
#include <vector>
#include <limits>
 
using namespace std;
 
inline float asm_cos( float  x)
{
    asm ("fcos" : "=t" (x) : "0" (x));
    return x;
}
 
 
int main()
{
    clock_t time1;
    clock_t time2;
    clock_t time3;
    clock_t time4;
    const int nbCalcul = 10000000;
    vector<float> test_cos(nbCalcul);
    double somme(0);
    for (int  i=0;i<nbCalcul;++i)
              somme+= fabs( cosf(static_cast<float>(i*2.f*M_PI/(nbCalcul-1)))-asm_cos(static_cast<float>(i*2.f*M_PI/(nbCalcul-1))));
    cout << "moyenne difference "<< somme/nbCalcul << endl;
    cout << "epsilon float "<< numeric_limits<float>::epsilon() << endl;
 
 
    for (int j=0;j<10;++j)
        {
        int i;
        time1 = clock();
        for ( i=0;i<nbCalcul;++i)
              test_cos[i] = cosf(static_cast<float>(i*2.f*M_PI/(nbCalcul-1)));
        time2 = clock();
 
        for (i=0;i<nbCalcul;++i)
                test_cos[i] = asm_cos(static_cast<float>(i*2.f*M_PI/(nbCalcul-1)));
        time3 = clock();
 
        time4 = clock();
        cout << "cos "<< static_cast<double>(time2 - time1) / CLOCKS_PER_SEC << endl;
        cout << "asm_cos "<<static_cast<double>(time3 - time2) / CLOCKS_PER_SEC << endl<< endl;
 
        }
 
 
    return 0;
}

La différences de résultat entre les cos semble négligeable (moyenne des differences < epsilon d'un float).
Ai je fait une erreur? Es ce que j'interprète mal les résultats?

Si quelqu'un à une réponse :roll:

Les instructions assembleurs fsin/fcos, même si elles nécessitent de nombreux cycles d'horloge et ne sont pas pipelinées, sont à ma connaissance plus rapides que les fonctions des librairies C/C++.

Mais si ça t'intéresses, y'a encore plus rapide à condition de sacrifier un tout petit peu en précision.
Cherche sur Google la "Approximate Math Library for Intel Streaming SIMD Extensions". C'est une petite bibliothèque gratuite d'Intel, livrée avec les sources.
Elle a en outre les avantages suivants:
-possibilité de faire des sin/cos/log... vectoriellement (4 floats, 2 doubles)
-si on utilise de toute façon les instructions SIMDs, il n'y a pas de transfert à faire d'un registre SSE/SSE2 vers un registre x87 (lent car passage par la mémoire)

Par exemple les 4 fonctions suivantes permettent de calculer un cosinus d'un seul float (am_cos_ss), de 4 floats (am_cos_ps), un seul double (am_cos_ess) ou 2 doubles (am_cos_eps)

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
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
/////////////////////////////////////////////////////////////////////////////
// am_cos_ps
 
__m128 __declspec(naked) __stdcall am_cos_ps(__m128 x)  // any x
{
	__asm
	{
		andps	xmm0, _ps_am_inv_sign_mask
		mov		ecx, esp
		addps	xmm0, _ps_am_pi_o_2
		mulps	xmm0, _ps_am_2_o_pi
		and		ecx, ~15
 
		movhlps	xmm2, xmm0
		cvttps2pi	mm0, xmm0
		movq	mm2, mm0
		cvttps2pi	mm1, xmm2
		pslld	mm2, (31 - 1)
		movq	mm3, mm1
		pslld	mm3, (31 - 1)
		pand	mm2, _pi32_0x80000000
		movq	[ecx - 32], mm2
		pand	mm3, _pi32_0x80000000
		movq	[ecx - 32 + 8], mm3
 
		cvtpi2ps	xmm4, mm1
		pand	mm1, _pi32_1
		ASM_MOVE_L2H(xmm4)
		pxor	mm7, mm7
		movaps	xmm5, _ps_am_1
		cvtpi2ps	xmm4, mm0
		pand	mm0, _pi32_1
		pcmpeqd	mm1, mm7
		subps	xmm0, xmm4
		movq	[ecx - 16 + 8], mm1
		minps	xmm0, xmm5
		pcmpeqd	mm0, mm7
		subps	xmm5, xmm0
		movq	[ecx - 16], mm0
 
		movaps	xmm6, [ecx - 16]
		andps	xmm0, xmm6
		andnps	xmm6, xmm5
		movaps	xmm3, _ps_sincos_p3
		orps	xmm0, xmm6
 
		movaps	xmm5, _ps_sincos_p2
		movaps	xmm1, xmm0
		mulps	xmm0, xmm0
		movaps	xmm7, [ecx - 32]
		movaps	xmm2, xmm0
		mulps	xmm0, xmm3
		movaps	xmm3, _ps_sincos_p1
		addps	xmm0, xmm5
		movaps	xmm5, _ps_sincos_p0
		mulps	xmm0, xmm2
		addps	xmm0, xmm3
		mulps	xmm0, xmm2
		orps	xmm1, xmm7
		addps	xmm0, xmm5
		mulps	xmm0, xmm1
 
		ret		16
	}
}
 
/////////////////////////////////////////////////////////////////////////////
// am_cos_eps
 
__m128 __declspec(naked) __stdcall am_cos_eps(__m128 x)  // any x
{
	__asm
	{
		andps	xmm0, _ps_am_inv_sign_mask
		addps	xmm0, _ps_am_pi_o_2
		mulps	xmm0, _ps_am_2_o_pi
 
		pxor	xmm3, xmm3
		movdqa	xmm5, _epi32_1
		movaps	xmm4, _ps_am_1
		cvttps2dq	xmm2, xmm0
		pand	xmm5, xmm2
		pcmpeqd	xmm5, xmm3
		cvtdq2ps	xmm6, xmm2
		pand	xmm2, _epi32_2
		pslld	xmm2, (31 - 1)
 
		subps	xmm0, xmm6
		minps	xmm0, xmm4
		subps	xmm4, xmm0
		andps	xmm0, xmm5
		andnps	xmm5, xmm4
		orps	xmm0, xmm5
 
		movaps	xmm1, xmm0
		mulps	xmm0, xmm0
		orps	xmm1, xmm2
		movaps	xmm7, xmm0
		mulps	xmm0, _ps_sincos_p3
		addps	xmm0, _ps_sincos_p2
		mulps	xmm0, xmm7
		addps	xmm0, _ps_sincos_p1
		mulps	xmm0, xmm7
		addps	xmm0, _ps_sincos_p0
		mulps	xmm0, xmm1
 
		ret		16
	}
}
 
/////////////////////////////////////////////////////////////////////////////
// am_cos_ss
 
__m128 __declspec(naked) __stdcall am_cos_ss(__m128 x)
{
	__asm
	{
		movss	xmm1, _ps_am_inv_sign_mask
		andps	xmm0, xmm1
		addss	xmm0, _ps_am_pi_o_2
		mulss	xmm0, _ps_am_2_o_pi
 
		cvttss2si	ecx, xmm0
		movss	xmm5, _ps_am_1
		mov		edx, ecx
		shl		edx, (31 - 1)
		cvtsi2ss	xmm1, ecx
		and		edx, 0x80000000
		and		ecx, 0x1
 
		subss	xmm0, xmm1
		movss	xmm6, _sincos_masks[ecx * 4]
		minss	xmm0, xmm5
 
		movss	xmm1, _ps_sincos_p3
		subss	xmm5, xmm0
 
		andps	xmm5, xmm6
		movss	xmm7, _ps_sincos_p2
		andnps	xmm6, xmm0
		mov		[esp - 4], edx
		orps	xmm5, xmm6
		movss	xmm0, xmm5
 
		mulss	xmm5, xmm5
		movss	xmm4, _ps_sincos_p1
		movss	xmm2, xmm5
		mulss	xmm5, xmm1
		movss	xmm1, _ps_sincos_p0
		addss	xmm5, xmm7
		mulss	xmm5, xmm2
		movss	xmm3, [esp - 4]
		addss	xmm5, xmm4
		mulss	xmm5, xmm2
		orps	xmm0, xmm3
		addss	xmm5, xmm1
		mulss	xmm0, xmm5
 
		ret		16
	}
}
 
/////////////////////////////////////////////////////////////////////////////
// am_cos_ess
 
__m128 __declspec(naked) __stdcall am_cos_ess(__m128 x)  // any x
{
	__asm
	{
		movss	xmm1, _ps_am_inv_sign_mask
		movss	xmm2, _ps_am_pi_o_2
		movss	xmm3, _ps_am_2_o_pi
		andps	xmm0, xmm1
		addss	xmm0, xmm2
		mulss	xmm0, xmm3
 
		pxor	xmm3, xmm3
		movd	xmm5, _epi32_1
		movss	xmm4, _ps_am_1
		cvttps2dq	xmm2, xmm0
		pand	xmm5, xmm2
		movd	xmm1, _epi32_2
		pcmpeqd	xmm5, xmm3
		cvtdq2ps	xmm6, xmm2
		pand	xmm2, xmm1
		pslld	xmm2, (31 - 1)
 
		subss	xmm0, xmm6
		movss	xmm3, _ps_sincos_p3
		minss	xmm0, xmm4
		subss	xmm4, xmm0
		andps	xmm0, xmm5
		andnps	xmm5, xmm4
		orps	xmm0, xmm5
 
		movaps	xmm1, xmm0
		movss	xmm4, _ps_sincos_p2
		mulss	xmm0, xmm0
		movss	xmm5, _ps_sincos_p1
		orps	xmm1, xmm2
		movaps	xmm7, xmm0
		mulss	xmm0, xmm3
		movss	xmm6, _ps_sincos_p0
		addss	xmm0, xmm4
		mulss	xmm0, xmm7
		addss	xmm0, xmm5
		mulss	xmm0, xmm7
		addss	xmm0, xmm6
		mulss	xmm0, xmm1
 
		ret		16
	}
}

13/01/2008, 15h33
yan

Merci pour la réponse.
Mais je suis trés étonné que GCC ou Visual ne l'utilise pas de base... Puisque c'est plus rapide et aussi précis.
C'est bon à savoir.
Tu ne connaitrai pas un papier qui liste ces fonctions asm qui plus rapide??
Tien comme tu t'y connait bien. Que pense tu de cela ?
http://ktd.club.fr/programmation/cpp-fastmath.php

Salut,

Le problème, c'est qu'il n'y a pas que les PC dans la vie, et que Gcc, par exemple, est prévu pour être compilable sur certaines de ces plateformes "non personnelles"...

Dés lors, prendre la décision d'utiliser des instructions propres à une famille de processeurs particulière, c'est, quelque part, prendre un pari qui menera à un certain "élitisme" (tu n'est pas assez bien pour m'utiliser, étant donné que tu n'utilise pas le bon processeur)...

En plus, sur mon "antique" Athlon 1700 XP, la différence est de l'ordre de 0.03 à 0.06 en faveur de la fonction STL, sans différence de précision (mais bon, c'est une compilation perso de Gcc et de tout ce qui va avec :P)

J'obtiens en effet les résultats suivants:
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 moyenne difference 0 epsilon float 1.19209e-007 cos 1.156 asm_cos 1.172 cos 1.125 asm_cos 1.172 cos 1.125 asm_cos 1.172 cos 1.14 asm_cos 1.188 cos 1.125 asm_cos 1.172 cos 1.14 asm_cos 1.172 cos 1.125 asm_cos 1.188 cos 1.125 asm_cos 1.172 cos 1.14 asm_cos 1.172 cos 1.125 asm_cos 1.172
Comme quoi, il ne faut jamais trop se fier à un benchmark que l'on n'a pas truqué soi meme :D (et pourtant, j'ai utilisé exactement ton code ;):D)

13/01/2008, 16h02
yan

ok merci.
13/01/2008, 16h10
Charlemagne

Citation:

Envoyé par Mongaulois

Merci pour la réponse.
Mais je suis trés étonné que GCC ou Visual ne l'utilise pas de base... Puisque c'est plus rapide et aussi précis.
C'est bon à savoir.
Tu ne connaitrai pas un papier qui liste ces fonctions asm qui plus rapide??
Tien comme tu t'y connait bien. Que pense tu de cela ?
http://ktd.club.fr/programmation/cpp-fastmath.php

A première vue, c'est intéressant d'un point de vue algorithmique, pour battre de vitesse des librairies C/C++.
Mais ça ne concurrence probablement pas des instructions assembleur spécifiques. Et encore moins des calculs SIMD.

Et puis je me méfierais des instructions telles que "fV = (fValue<0.0) ? -fValue : fValue" qui risquent fort de faire un saut conditionnel et de briser e pipeline du processeur.

Les instructions SSE/SSE2 n'ont pas de fonctions trigo ou logarithmique, d'où le rôle de l'approximate Math Library d'Intel.
Mais y'a quand même la racine carrée, imbattable...

Si tu as l'aide de Visual, entre "SSE" dans l'index, et tu verras tous les intrasics.

Citation:

Envoyé par koala01

Le problème, c'est qu'il n'y a pas que les PC dans la vie, et que Gcc, par exemple, est prévu pour être compilable sur certaines de ces plateformes "non personnelles"...

Mais quand-même, GCC a des options spécifiques pour optimiser sur divers processeurs (-march, -msse...). A quoi bon ces options alors?
Mais en l'occurence, je crois que c'est un problème de bibliothèque plus que de compilo. Le compilo C++ d'Intel sous Windows venant par exemple avec sa propre lib mathématique.
13/01/2008, 16h14
yan

Citation:

Envoyé par koala01

Comme quoi, il ne faut jamais trop se fier à un benchmark que l'on n'a pas truqué soi meme :D (et pourtant, j'ai utilisé exactement ton code ;):D)

Hé mais euh... j'ai rien truqué...
Ca me rassure que tu n'as pas les même resultats
13/01/2008, 20h22
Jean-Marc.Bourguet

Citation:

Envoyé par Mongaulois

Mais je suis trés étonné que GCC ou Visual ne l'utilise pas de base... Puisque c'est plus rapide et aussi précis.

As-tu vérifié le dernier point dans tous les cas tordus sur tous les processeurs potentiellement cibles?

En ce qui concerne gcc, il doit y avoir des raisons que tu ignores (par exemple, la doc que j'ai précise que l'argument de FSIN doit se trouver entre -2^63 et 2^63) parce que -ffast-math génère des FSIN sans problèmes.
13/01/2008, 21h19
yan

Citation:

Envoyé par Jean-Marc.Bourguet

As-tu vérifié le dernier point dans tous les cas tordus sur tous les processeurs potentiellement cibles?

En ce qui concerne gcc, il doit y avoir des raisons que tu ignores (par exemple, la doc que j'ai précise que l'argument de FSIN doit se trouver entre -2^63 et 2^63) parce que -ffast-math génère des FSIN sans problèmes.

Euh non. Je ne connait pas tout les cas tordu :aie:
C'est pour ça que j'ai fait un thread.
C'est surtout par rapport à
http://www.developpez.net/forums/sho...55&postcount=8

Je voulais vérifier ses dire. Comme quoi c'est pas si simple

Merci beaucoup
13/01/2008, 23h34
loufoque

Tu compiles bien en -O3 -march=native ?

Citation:

Envoyé par Charlemagne

Mais quand-même, GCC a des options spécifiques pour optimiser sur divers processeurs (-march, -msse...). A quoi bon ces options alors?
Mais en l'occurence, je crois que c'est un problème de bibliothèque plus que de compilo. Le compilo C++ d'Intel sous Windows venant par exemple avec sa propre lib mathématique.

Ca, ca permet de créer des applications spécifiques pour une plateforme données, en utilisant un compilateur qui, lui, peut etre fournis pour toutes ;)

Citation:

Envoyé par Mongaulois

Hé mais euh... j'ai rien truqué...
Ca me rassure que tu n'as pas les même resultats

Je te rassure, je n'ai jamais pensé que tu avais truqué quoi que ce soit...

Ce que je voulais dire, c'est qu'il y a tellement de paramètres qui peuvent faire que les résultats diffèrents d'une machine à l'autre que, en définitivie, le crédit à donner à un benchmark reste tout relatif ;)

D'ailleurs, je me suis rendu compte que les résultats fournis étaient ceux obtenus en mode debug, sans optimisation particulière...

En effectuant le test en -O3 march=athlon, les résultats sont inversés (mais avec une moindre différence):
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 moyenne difference 0 epsilon float 1.19209e-007 cos 1.046 asm_cos 0.922 cos 1.016 asm_cos 0.937 cos 1.016 asm_cos 0.906 cos 1.016 asm_cos 0.922 cos 1.031 asm_cos 0.922 cos 1.016 asm_cos 0.937 cos 1 asm_cos 0.922 cos 1.031 asm_cos 0.922 cos 1 asm_cos 0.938 cos 1.015 asm_cos 0.922
Tu vois qu'il ne faut apporter aucun crédit à un benchmark que tu n'a pas truqué toi meme :D

14/01/2008, 10h26
Emmanuel Deloget

Citation:

Envoyé par Mongaulois

Merci pour la réponse.
Mais je suis trés étonné que GCC ou Visual ne l'utilise pas de base... Puisque c'est plus rapide et aussi précis.

La raison pour laquelle MS VC++ ou GCC n'utilise pas de base les fonctions asm est que si, en fait, elles les utilise. Mais le standard C et C++ définit un comportement bien plus complet que le seul comportement des fonctions asm, ce qui impose d'autres opérations - notamment pour vérifier si le float ou le double n'est pas dénormalisé ou pour traiter les autres conditions d'erreur (range, ...). Donc, au final, le résultat de l'appel direct de la fonction asm est très similaire dans la plupart des cas, peut être très différent dans certains cas (et provoquer de fait des bugs très difficiles à localiser), mais est intrinsèquement plus rapide puisque tout un ensemble de vérifications importantes ne sont pas effectuées.
14/01/2008, 14h27
loufoque

Citation:

D'ailleurs, je me suis rendu compte que les résultats fournis étaient ceux obtenus en mode debug, sans optimisation particulière...

Des benchmarks en mode debug... C'est n'importe quoi.
14/01/2008, 14h48
koala01

Citation:

Envoyé par loufoque

Des benchmarks en mode debug... C'est n'importe quoi.

C'est pas du n'importe quoi, c'est juste de la distraction ;)