PDA

View Full Version : OT: Cos and Sin tables



blood.angel
06-22-2002, 09:29 AM
Instead of using glRotate() for a camera I was thinking of constructing sin and cos tables and using that.

I was looking at old gaming making tutorials and they say such tables speed up the code. Does that still hold today? Or is it that it doesnt matter with todays faster CPUs?

IronRaph
06-22-2002, 09:40 AM
do your table http://www.opengl.org/discussion_boards/ubb/smile.gif

Bob
06-22-2002, 10:32 AM
I suggest you go for the functions, not look up tables. CPU's are fast enough.

Anyways, if performance matters, this is one of the last places you should care about. Algorithmic optimization (choose the right way instead of doing the wrong way as fast as possible) is WAY more efficient

zed
06-22-2002, 12:26 PM
>>I was looking at old gaming making tutorials<<

the key word here is 'old' since the pentium even the 486 this is not an isse in fact it will be slower when youre using them with glRotatef(..)
the only place where they would improve performance is if youre calculating 1000's of sin/cos in a very tight inner loop.
but even with this ild still go with cos/sin + not the tables ie the next cpu might do sos/cos's in 1 cycle

zeckensack
06-22-2002, 07:01 PM
I acutally tried that. I had some kind of coarse sine/cosine lookup table (128 entries) and did a linear interpolation between two entries. I though something like "Hey, that's only one kilobyte, should be nice on the caches. There's no way FSINCOS can be faster.". Of course FSINCOS was faster than this 'optimization'. And more precise to boot.

(On my old system, Athlon 'Classic' 600, 100MHz el cheapo SDRAM).

Robbo
06-23-2002, 06:52 AM
Just out of interest - can someone tell me what is wrong with the following item?

Cheers!


inline void sincos ( float Ang, float& Sin, float &Cos )
{
__asm {

fld Ang
fsincos
fstp Cos
fstp Sin
}
}

Thug
06-25-2002, 05:15 AM
Zed,
The only thing wrong with you logic, is that I do not see any CPU in the next few decades making a sine or cosine call run in 1 cycle. The faster the CPU just runs the same number of cycles faster nothing more. If a CPU could spit out an answer for sine or cosine in 1 cycle that would imply that the CPU circuitry would have sine and cosine logic added on the chip itself. However, if that happens it may take several cycles due to sine and cosine are too complicated functions. As far as I know, multiplication is not even directly encoded on the chip. It is just a bunch of additions... that is why adding is faster than multiplying.

pleopard
06-25-2002, 06:07 AM
Originally posted by Robbo:
Just out of interest - can someone tell me what is wrong with the following item?

Cheers!


inline void sincos ( float Ang, float& Sin, float &Cos )
{
__asm {

fld Ang
fsincos
fstp Cos
fstp Sin
}
}

I cannot tell you why there is a problem but I can verify that there is a problem with it ...




#include <iostream>

using namespace std;

inline void sincos ( float Ang, float&amp; Sin, float &amp;Cos )
{
__asm
{
fld Ang
fsincos
fstp Cos
fstp Sin
}
}

#define PI 3.141592654
#define DEG_TO_RAD PI/180.0f

void main()
{
float dAng,fAng;
float fSin,fCos;
for (dAng=0.0f; dAng<360.0f; dAng += 5.0f)
{
fAng = dAng*DEG_TO_RAD;
sincos(fAng,fSin,fCos);
cerr << dAng << ", " << fSin << ", " << fCos << endl;
}
}


And the output is ...



0, 5.88346e-039, 5.88387e-039
5, 5.88346e-039, 5.88387e-039
10, 5.88346e-039, 5.88387e-039
15, 5.88346e-039, 5.88387e-039
20, 5.88346e-039, 5.88387e-039
25, 5.88346e-039, 5.88387e-039
30, 5.88346e-039, 5.88387e-039
35, 5.88346e-039, 5.88387e-039
40, 5.88346e-039, 5.88387e-039
45, 5.88346e-039, 5.88387e-039
50, 5.88346e-039, 5.88387e-039
55, 5.88346e-039, 5.88387e-039
60, 5.88346e-039, 5.88387e-039
65, 5.88346e-039, 5.88387e-039
70, 5.88346e-039, 5.88387e-039
75, 5.88346e-039, 5.88387e-039
80, 5.88346e-039, 5.88387e-039
85, 5.88346e-039, 5.88387e-039
90, 5.88346e-039, 5.88387e-039
95, 5.88346e-039, 5.88387e-039
100, 5.88346e-039, 5.88387e-039
105, 5.88346e-039, 5.88387e-039
110, 5.88346e-039, 5.88387e-039
115, 5.88346e-039, 5.88387e-039
120, 5.88346e-039, 5.88387e-039
125, 5.88346e-039, 5.88387e-039
130, 5.88346e-039, 5.88387e-039
135, 5.88346e-039, 5.88387e-039
140, 5.88346e-039, 5.88387e-039
145, 5.88346e-039, 5.88387e-039
150, 5.88346e-039, 5.88387e-039
155, 5.88346e-039, 5.88387e-039
160, 5.88346e-039, 5.88387e-039
165, 5.88346e-039, 5.88387e-039
170, 5.88346e-039, 5.88387e-039
175, 5.88346e-039, 5.88387e-039
180, 5.88346e-039, 5.88387e-039
185, 5.88346e-039, 5.88387e-039
190, 5.88346e-039, 5.88387e-039
195, 5.88346e-039, 5.88387e-039
200, 5.88346e-039, 5.88387e-039
205, 5.88346e-039, 5.88387e-039
210, 5.88346e-039, 5.88387e-039
215, 5.88346e-039, 5.88387e-039
220, 5.88346e-039, 5.88387e-039
225, 5.88346e-039, 5.88387e-039
230, 5.88346e-039, 5.88387e-039
235, 5.88346e-039, 5.88387e-039
240, 5.88346e-039, 5.88387e-039
245, 5.88346e-039, 5.88387e-039
250, 5.88346e-039, 5.88387e-039
255, 5.88346e-039, 5.88387e-039
260, 5.88346e-039, 5.88387e-039
265, 5.88346e-039, 5.88387e-039
270, 5.88346e-039, 5.88387e-039
275, 5.88346e-039, 5.88387e-039
280, 5.88346e-039, 5.88387e-039
285, 5.88346e-039, 5.88387e-039
290, 5.88346e-039, 5.88387e-039
295, 5.88346e-039, 5.88387e-039
300, 5.88346e-039, 5.88387e-039
305, 5.88346e-039, 5.88387e-039
310, 5.88346e-039, 5.88387e-039
315, 5.88346e-039, 5.88387e-039
320, 5.88346e-039, 5.88387e-039
325, 5.88346e-039, 5.88387e-039
330, 5.88346e-039, 5.88387e-039
335, 5.88346e-039, 5.88387e-039
340, 5.88346e-039, 5.88387e-039
345, 5.88346e-039, 5.88387e-039
350, 5.88346e-039, 5.88387e-039
355, 5.88346e-039, 5.88387e-039

zeckensack
06-26-2002, 08:47 AM
Originally posted by Robbo:
Just out of interest - can someone tell me what is wrong with the following item?

Cheers!


inline void sincos ( float Ang, float& Sin, float &Cos )
{
__asm {

fld Ang
fsincos
fstp Cos
fstp Sin
}
}
Cos and Sin in this function are pointers. You need some dereferencing.

Do something like

fld Ang
fsincos
MOV ESI,Cos
MOV EDI,Sin
fstp [ESI]
fstp [EDI]
Cheers.

Nothing
06-26-2002, 09:27 AM
Bear in mind that FSINCOS expects the angle in radians not in degrees.