[gameprogrammer] Re: Fixed point vs floating point in modern computers

  • From: Gato <gato@xxxxxxxxxxxx>
  • To: gameprogrammer@xxxxxxxxxxxxx
  • Date: Sun, 19 Feb 2012 17:52:14 -0600

On 2/19/2012 3:34 PM, Alan Wolfe wrote:
Hey Guys,

I was curious, does anyone know any metrics about how fast fixed point math operations are compared to floating point math operations on modern desktops/laptops?

There's an annoying issue i've been trying to solve in my google native client app where some systems have different levels of floating point math precision (internal float registers being 80 bits sometimes, and sometimes not, different machines spilling calculations onto the stack for temporaries etc) and while i've been talking to the google nacl devs on the mailing list, i'm wondering if going to fixed point may be a decent solution.

The worry of mine though is that going to fixed point i'd lose out on any SSE operations as well as perhaps thinking that even well written fixed point math may not be as fast as hardware calculated floating point math.

But, of course what would be great is that whatever i see on my machine is what other people would see on theirs, which is really attractive.

This is for a raytracer so is very heavy on floating point computation, and apparently pretty sensitive to floating point precision issues.

What do you guys think, anyone have any insight or input?

You wouldn't gain much precision-wise by using fixed point unless you've been using 32 bit float (floats generally have only 23 bits of mantissa, while doubles have 52), and very likely would lose performance. Compilers are good at interleaving floating point instructions and the rest of the program, as they usually execute in parallel (at least on modern x86 CPUs). I'd say, rather than jumping on to fixed point math just yet, try to identify why the algorithm is sensitive to floating point imprecision.

Usually there are two strategies you can use to deal with floating point imprecision:

The first one is reorganize the formulas. For example, you're making a ray tracer, so I assume one of the things you would want to do is solve a quadratic equation (used in ray-sphere intersection). We all know how to solve quadratic equations:

x = (-b ± sqrt(b^2 -4*a*c)) / (2*a)

However, when the term 4ac is small, with the fixed precision of floats one of the roots can vanish to 0. To avoid that, it's better to obtain one root (pick the sign of the square root, so it is the same -b has), and find the other root with x2 = c / (a * x1)

As a rule of thumb, you want to avoid terms cancelling each other.

The other strategy is to have a fast algorithm to solve most of the cases, and use a slower but more precise one just for special cases.


Other related posts: