static class members

I have a polygon class, and in order to incorporate roation into it, I wanted to generate cosine and sine lookup tables, as my book suggests:

Code:

void _POLYGON2D::GenerateTables()
{
for (int ang = 0;ang<360;ang++)
{
float theta = static_cast<float>(ang*3.14159/180);
cos_look[ang] = cos(theta);
sin_look[ang] = sin(theta);

}

}

(cos_look and sin_look are float arrays within the class)
Of course this doesn't seem like a good way, since I want to create polygons using some sort of linked list, i would have to call this function every time I added a new one...Could I declare cos_look and sin_look static like this:

Code:

typedef _POLYGON2D
{
public:
//...
void GenerateTables();

//...

private:
static float sin_look[360];
static float cos_look[360];

} Polygon2D, *PtrPolygon2D;

If my understanding is correct, declaring members static gives the the same values throughout all instances of the class, so could I just call GenerateTables() once like this:

Code:

//in initialization function
Polygon2D::GenerateTables();

And then have the arrays be initialized for all my polygon objects?

Actually declaring those as static means that if another class inherits from your base class only one copy of cos and sin tables exist. So in essence what you said is true. Each instance of the class will retain the cos and sin tables.

Actually declaring those as static means that if another class inherits from your base class only one copy of cos and sin tables exist. So in essence what you said is true. Each instance of the class will retain the cos and sin tables.

But what if I have

Code:

Polygon2D one;
Polygon2D two;

Their tables will be the same, correct?

Yes.

You could use lazy evaluation now that you have a single static table. Instead of calling GenerateTables once during initialization, just use a set or hash_set that starts off empty. Then when sin(angle) is needed, you check to see if it has been generated yet and if it has just return it. If not, generate it then and add it to the set for next time. This would help if you don't use all the angles. By using a set instead of an array you'd save the computation time plus the space required for the unused floats. The cost is the lookup, but in a hash_set that is supposed to be nearly the same as for an array.

But it would take more time to look up the value in a table than to do an FSIN on the FPU.

I will most likely need all the angles, and my goal is to minimize the time it takes to calculate rotations so generating the lookup tables during initialization is probably best

Originally posted by Bubba
But it would take more time to look up the value in a table than to do an FSIN on the FPU.

Not really....there's no hard and fast rule.....it would depend on a lot of things

What book are you using.
The book I am reading uses global variables for the tables. I know everyone hates the overuse of global variables but LaMothe claims they are faster for game design purposes.

Globals and statics members are usually stored in the same section so there isnt often too much of a difference......Look in LaMothe's book about what he says about C++ - he uses it, but ignores much of the more oop facilities that it provides.....just a matter of taste - you can access a public static table just as with a global;

MyClass::MyTable[10] = 50.23;

[edit] as for faster, thats usually to avoid passing pointers or values to functions

Not really....there's no hard and fast rule.....it would depend on a lot of things

Yes it would. But my point is that some optimizations that we use...including you and I Fordy...may actually be slower than just using the FPU - but not in this case. I stand corrected.

FSIN
OPCODE: D9 FE
BINARY: 11011 001: 1111 1110
Replace ST(0) with its sine

IF ST(0)<2^63
THEN
C2<-0
ST(0)<-sin(ST(0))
ELSE (*source operand out of range*)
C2<-1
FI:


FSIN clock cycles
80486 - 241 (193-279)
Pentium IA-32 - must use performance counter; value not given
Itanium IA-64 - same as IA32
AMD IA32 - no documentation (perhaps Fordy has this)

It is interesting to note that the process for achieving the sine of ST(0) on IA-32 and IA-64 are identical to each other. Seems that the FSIN opcode has not been changed since the 80486.

Safe to say that FSIN probably runs in the range of 200 to 240 clock cycles with 2 concurrent executions required - total of nearly 400 to 480 clocks.

So Fordy is probably right in that a memory look up takes far less than that.

Assuming that we are loading from an array:

lds esi,[FloatArray] - roughly 12 clocks on 486
;fld m32real Push m32real onto FPU stack
fld ds:[esi+offset] - roughly 3 clocks



So it takes about 15 clocks to retrieve a value from a floating point array on a 80486.

So a look-up table based on a pure opcode and instruction timing comparison is much faster than the FPU.

The IA32 and IA64 FSIN's appear to only require one execution to perform the task thus dropping the cycles by half.