• FEATURED

View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

# float vs double

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

49 replies to this topic

### #21DrEvil  Members

Posted 06 September 2005 - 01:58 AM

MS recently said at one of their XBox 360 conferences that double is native and therefor faster to the platform. I second the recommendation of using typedefs for your floating point types, to facilitate simple switching between the resulting types used. This could cause compatability problems in file IO and other such things, so a bit of care must be taken.

### #22blizzard999  Members

Posted 06 September 2005 - 01:58 AM

Quote:
Original post by Nitage
Quote:
 Original post by blizzard999In my opinion on modern processors (like P4 and its 128 bit SIMD floating point arithmetic) using floats give no speed benefits.

There are 128 bit instructions where those 128 bits hold 4 floats.
There are 128 bit instructions where those 128 bits hold 2 doubles.

Using floats with 128bit instructions can give a 100% speed up over doubles

Example ?

### #23MENTAL  Members

Posted 06 September 2005 - 02:10 AM

Quote:
Original post by blizzard999
Quote:
Original post by Nitage
Quote:
 Original post by blizzard999In my opinion on modern processors (like P4 and its 128 bit SIMD floating point arithmetic) using floats give no speed benefits.

There are 128 bit instructions where those 128 bits hold 4 floats.
There are 128 bit instructions where those 128 bits hold 2 doubles.

Using floats with 128bit instructions can give a 100% speed up over doubles

Example ?

because you can do twice as many calculations with floats than doubles. 4 is 100% higher than 2.

### #24vNistelrooy  Members

Posted 06 September 2005 - 02:12 AM

What example do you want? xmm0 can hold either 4 floats or 2 doubles. 2x the data calculated, plus you don't need to use SSE2, which all AthlonXPs (still very popular) don't support.
"C lets you shoot yourself in the foot rather easily. C++ allows you to reuse the bullet!"

### #25Nitage  Members

Posted 06 September 2005 - 02:21 AM

Quote:
Original post by blizzard999
Quote:
Original post by Nitage
Quote:
 Original post by blizzard999In my opinion on modern processors (like P4 and its 128 bit SIMD floating point arithmetic) using floats give no speed benefits.

There are 128 bit instructions where those 128 bits hold 4 floats.
There are 128 bit instructions where those 128 bits hold 2 doubles.

Using floats with 128bit instructions can give a 100% speed up over doubles

Example ?

SSE3 instructions:

Input: { A0, A1 }, { B0, B1 }
Output: { A0 - B0, A1 + B1 }

Input: { A0, A1, A2, A3 }, { B0, B1, B2, B3 }
Output: { A0 - B0, A1 + B1, A2 - B2, A3 + B3 }

Twice as much gets done in the same time using floats. Therfore floats can be 100% faster.

### #26blizzard999  Members

Posted 06 September 2005 - 03:46 AM

Thanks

### #27Riviera Kid  Members

Posted 06 September 2005 - 05:40 AM

Quote:
 Original post by BasirorI just looked something up, SSE2 is supposed to support 128bit registers to perform 2 double precision operations in one step

yeah but you can also do 4 floating point precision operations in one step.

you get 8 of them registers i think
which makes matrix*matrix very fast. You can the first matrix in the first 4 registers (4 * 4 matrix) then the next matrix in the next 4 registers. If you are using double it will take atleast twice as long.

I havent put this into practice but i remember the theory in my book. Maybe there are other things to consider which i have missed.

there is also the shuffle operation which uses 4 floats. If you are using doubles youll be messing around with 2 registers and moving stuff manually - slow.

Yeah, graphics processors and fpu's are usually (afaik) optimized to use floats.

### #28Drethon  Members

Posted 06 September 2005 - 06:11 AM

Quote:
 NEVER EVER use == on a float

Very true, a most useful function for any program dealing with floating values:

bool compareFloat ( float Value1 , float Value2 , float Tolerance ){   if ( fabs ( Value1 - Value2 ) &lt; Tolerance )      return true ;   else      return false ;}

The tolerance can be hard coded if desired.

(Pardon if my formatting is off, I've been programming in so many C variant scripting languages lately I can't keep em straight...)

### #29Basiror  Members

Posted 06 September 2005 - 06:30 AM

Quote:
Original post by Riviera Kid
Quote:
 Original post by BasirorI just looked something up, SSE2 is supposed to support 128bit registers to perform 2 double precision operations in one step

yeah but you can also do 4 floating point precision operations in one step.

you get 8 of them registers i think
which makes matrix*matrix very fast. You can the first matrix in the first 4 registers (4 * 4 matrix) then the next matrix in the next 4 registers. If you are using double it will take atleast twice as long.

I havent put this into practice but i remember the theory in my book. Maybe there are other things to consider which i have missed.

there is also the shuffle operation which uses 4 floats. If you are using doubles youll be messing around with 2 registers and moving stuff manually - slow.

Yeah, graphics processors and fpu's are usually (afaik) optimized to use floats.

yes i know but in some cases this leads to some little problems concerning precision
the few matrix operations i have to perform aren t critical anyways since most of the work will be moved to the gpu its optimized for this kind of operations

### #30iforce2d  Members

Posted 07 September 2005 - 02:48 AM

Quote:
 NEVER EVER use == on a float
I do something like this occasionally:
float val = MAXFLOAT;...loop which may change val...if (val == MAXFLOAT)    ...
I haven't had any problems with this but admittedly I'm mostly only running debug builds where this just might be ok. Is it likely to screw up on different platforms or with different compile flags maybe?

### #31Nitage  Members

Posted 07 September 2005 - 02:52 AM

Quote:
Original post by zppz
Quote:
 NEVER EVER use == on a float
I do something like this occasionally:*** Source Snippet Removed ***I haven't had any problems with this but admittedly I'm mostly only running debug builds where this just might be ok. Is it likely to screw up on different platforms or with different compile flags maybe?

const float Y;float X = Y;....if(X==Y){}

That will work fine to check if the code does not modify X, but if you alter the value of X at all it may not work due to rounding errors in whatever function you used.

### #32MauMan  Members

Posted 07 September 2005 - 02:57 AM

Quote:
 NEVER EVER use == on a float

Sometimes I've thought to myself that using == or != on a float or double should arguably be a compiler warning. It does not work the way that most people expect it to work :-( At least until they really understand the problem

### #33BittermanAndy  Members

Posted 07 September 2005 - 09:37 AM

Quote:

Quote:
 Quote:Original post by BittermanAndyFloats are not always faster than doubles. For example on the platform I'm working on now, doubles are actually faster, as all floating point operations are native to doubles so floats get converted to doubles and back anyway. The extra memory is also unlikely to be an issue.

the playstation 2 doesn't have double precision support

And? I'm not working on PS2.

The point is, the question "are floats or doubles faster?" has only one answer: "depends on your platform".

### #34Daggett  Members

Posted 07 September 2005 - 11:37 AM

I made a small app to test the time difference using the performance counter. On 10,000 divisions (10,000 with floats and 10,000 with doubles), I expected the doubles to be at least a little slower, but I found they were exactly the same, sometimes one or the other was faster, but on average they were exactly the same.
However, I could see how memory bandwidth could be an issue in some games. If you have 10mb of vertex data with floats and 20mb with doubles, you'll defiantly see a performance hit using doubles.

### #35RobTheBloke  Members

Posted 08 September 2005 - 07:41 AM

10,000 divisions is really not a very complicated test for a CPU. It's a bit like asking me if taking one step backwards can be completed in the same time as taking one step forward - the difference is negligable.

on the bog standard 0x86 FPU, all calcs happen at 80bits, whether they are double or float. however, the 0x86 can read only 4bytes at a time. So (assuming that the data is 4byte aligned), a double requires 2 reads to get it into memory, a float requires a single read.

Now for say 1 million vertices, you'd need 12,000,000 bytes to store those as floas. (approx 12mb). To store those as double, youd need approx 24mb. It is a noticable enough difference to suggest that ideally, if you can handle the lack of precision, floats are preferable. (the read times would start to have an impact on those numbers, but it will not be a *big* hit).

As mentioned, SIMD can process 4 floats or 2 doubles in a single instruction, though it's likely that only a few people here are likely to use that (DX maths has built in aligned vector types that do work with SIMD, so maybe....)

The problem with floats, is that rounding errors accumulate much quicker than they do with doubles. An inverse matrix op with floats normally requires you to orthogonalise the matrix afterwards due to rounding errors.

So, try to use floats if possible. Use doubles if that's too inaccurate. Generally though, it's only really the maths calculations that will be affected. For renderable data, floats would be far more sensible.....

### #36RobTheBloke  Members

Posted 08 September 2005 - 07:49 AM

another place it may be noicable is when storing characters positions. If your character starts at a position of 0,0,0. Then floats will start losing precision as ou move further away from that point.

ie, at coords 100000,100000,100000 you may only have a small precision left to deal with....

### #37HalcyonX  Members

Posted 08 September 2005 - 08:29 AM

Thanks for the replies, everyone. Ill try to stick to floats when possible.

Quote:
 For renderable data, floats would be far more sensible.....

What exactly is "renderable data"? Is it things like colors, polygon vertex coordinates, etc.?

Quote:
 another place it may be noicable is when storing characters positions. If your character starts at a position of 0,0,0. Then floats will start losing precision as ou move further away from that point.ie, at coords 100000,100000,100000 you may only have a small precision left to deal with....

So i should store object position coordinates as floats? But these values are passed to openGL's translate function when I render, which then gets put into a matrix and is multiplied with all the verticies. Does this count as "renderable data"? Should i cast them to floats before calling the translation function? Thanks.

### #38iMalc  Members

Posted 08 September 2005 - 08:32 AM

All you need to know is that floats are good enough in most cases. Better to use floats initially (as a typedef though) and only if you find problems, or suspect problems should you switch.
It's far easier than starting with doubles and then switching to floats, as then you could break something due to the slight loss in accuracy.

### #39Anonymous Poster_Anonymous Poster_*  Guests

Posted 08 September 2005 - 12:39 PM

Quote:
 Original post by iMalcAll you need to know is that floats are good enough in most cases. Better to use floats initially (as a typedef though) and only if you find problems, or suspect problems should you switch.It's far easier than starting with doubles and then switching to floats, as then you could break something due to the slight loss in accuracy.

Concur. Unless you're doing scientific work, floats are probably the way to go.

### #40Daniel Miller  Members

Posted 08 September 2005 - 05:41 PM

If you shouldn't use == or !=, then wouldn't > and < be messed up as well?

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.