I know this topic has probably been discussed, but when I search for "float to int conversions" it says I used only ignored words. Whatever. Anyway, I know that C float to int conversions are slow, but how slow are they? Should I use an external function, like the one in the fast math library on the nVidia developer page? How fast is that? Thanks.

I heard that converting float to int takes 6 cpu cycles ... which is _extremely_ slow. If some external function is faster, then you should definitely use it.

~~~~~~~~~~
Martee
http://www.csc.uvic.ca/~mdill

I heard 7 on some message board somewhere, but I didn''t know if that was slow or not.

oh wait... 7? Damn thats bad!

I hear that you should totally avoid floats

Actually, to tell ya the truth, DWORDs might be faster than floats. They are the size of unsigned integers, and although unsigned themselves, they can handle floating-point numbers. Since they're 32-bit they are optimized on the pentium or something or other... but thats just uninformed ramblings, most likely totally wrong

Edited by - Zipster on April 28, 2001 12:40:01 AM

These days, using floating point is not some big no-no like it used to be. Floating point units in modern CPUs are extremely fast and are at least on par with integer calculations, from what I''ve heard. Regardless, they''re not rediculously slow like they used to be, and certainly not slow enough to avoid altogether.

Using unsigned integers (the same as DWORDS, for all intents and purposes) is not a great idea unless you''ll never need any fractional precision. If you only need positive whole numbers, unsigned integers are perfect. Otherwise, use floating point. Some might argue that creating a fixed point class which uses an unsigned integer to contain the actual number is really not a good idea anymore and ends up being slower on modern processors. Use floating point.

Casting from floating point to integers is slow. It''s faster if you cast to a signed integer. I haven''t exhaustively tested that NVIDIA code, so I''d suggest doing your own testing to determine whether or not it actually is faster. Do casts for an array or randomly-generated floats, and--of course--regenerate that list when you switch methods.

This might be wrong, but isn''t a DWORD just a typedef for an unsigned long? If so, I don''t really understand the comment that a DWORD is better than an integer, or how it can handle floating point info; it''s the same thing as an integer.

Anthracks

Hmm I think I might have been confusing a DWORD with a double . Anywayz, a DWORD is the like an unsigned int since nowadays integers are 32-bit also as opposed to old DOS dayz.

Oy...

3x86:

byte = 8 bits
word = 16 bits
dword = 32 bits
qword = 64 bits
tword = 80 bits

C interpretations of 3x86 memory holders:
unsigned char = byte
signed char = 2''s complemented byte
unsigned short int = word
signed short int = 2''s complemented word
unsigned long int/unsigned int = dword
signed long int/signed int = 2''s complemented dword
float = dword
double = qword
long double = tword

the x87 floating point unit keeps everything in the 80 bit tword format internally, and outputs it to whatever format you request (float, double, long double, signed int).

conversions from the x87 to another float format are fast, because all it needs to do is truncate or round the mantissa (based on the chop mode enabled) and truncate the exponent.

conversion to an integer format takes time, because it needs to remove the sign bit, and figure out where the mantissa goes based on the exponent.






The terms BYTE, WORD, DWORD, QWORD, and TWORD are all used to specify an unformatted chunk of bits, whereas the C types of CHAR, INT, SHORT, LONG, FLOAT, DOUBLE and LONG DOUBLE all specify formatted numbers of some sort.

===============================================
Have I no control, is my soul not mine?
Am I not just man, destiny defined?
Never to be ruled, nor held to heel!