Being interested in C++ performance programming there is one aspect I really have no clue about- and that is the implications of using floating point calculations vs doubles vs normal integer mathematics?

What performance issues with these types of calculations should I consider? What other issues need to be considered when deciding which kind of operators to use?

All I currently know is that doubles are probably the most expensive because they are larger, floating point is next and then integer calculations are usually the fastest on a CPU because they are much simpler.

  • 5
    ints are generally faster than floating points but beyond that it depends on architecture (whether a 32 bit and/or a 64 bit floating point ALU is available) Mar 12 '13 at 22:02
  • 1
    On PCs, long doubles are faster than floats, as the CPU can only handle integers and long doubles, so floats have to be converted all the time.
    – Sjoerd
    Mar 12 '13 at 22:59
  • 3
    Profile first, optimize after. Mar 12 '13 at 23:15
  • 2
    In my experience, 90% of applications that use floating point numbers have bugs as a result, and 90% of those could get the same results using integers. Therefore, my main concern with floating point code is usually "does it work" not "does it work fast enuf"
    – mattnz
    Mar 13 '13 at 0:04
  • 3
    Only use floating point if your data is an estimate. Mar 13 '13 at 0:40

The comments by @ratchet, @Sjoerd and @Stephane answer you question.

Your assertion in the question "All I currently know is that doubles are probably the most expensive because they are larger" shows the rules about optimization - are true - "Only for experts" followed by the "Your not an expert yet" .....

Unless you know the minutest details of the underlying hardware AND how the compiler utilizes those, you cannot make any assertions about floating point numbers. You can't even be certain that a floating point operation takes more time than an integer operation. As a rule, there is enough problems with programmers writing floating point code correctly, that it should be avoided unless needed. If needed, performance is of little concern.

As a rule of thumb - use ints if possible - it's rarely slower then FP operations, and often faster, and more predictable. If you must use FP operations, use doubles. Floats do not have a large enough mantissa for anything but the roughest of calculations (unless extreme care is taken) and a prone to insidious rounding errors.

However, like all rules of thumb, they need to be applied appropriately. If it matters - measure it.

  • This is sound advice. In my experience, there is a frightening amount of programmers who think "my number has a decimal point and therefore I must use float". For example: "The specification says that my program should calculate the length in meters, the output can be anything from 0 to 9.99. Therefore I must use float." Think outside the box and rewrite the program so that it uses centimeters! 0-999 centimeters can fit in a 16 bit integer, there is no reason why you would need float.
    – user29079
    Mar 14 '13 at 15:52

Use the Right Tool for the Job

Remember the old saw about the man who only had a hammer?

There are many integer and many floating point types and there are many implementations for them. If you get to know these well, it will make your results better, not to mention your code. When you make your choices, you will use several criteria.


If your application basically uses whole numbers, generally use integers. In C++ you have both signed (the default) and unsigned, and selecting unsigned will not only give you almost twice the maximum limit, it may permit the compiler to warn you about unwise uses of your number.

If it uses decimal values, often a floating point representation may be better. First, it may be more natural to program an equation from science, engineering, or business when the values are not restricted to whole numbers. Binary coded decimal (BCD) can also help with currency and although it takes more space and is slower, it has some desirable characteristics when used appropriately.

If you application relates to currency, that might be a tricky one because floating point is not precise, so occasionally you can gain or lose cents due to rounding. Sometimes you can manipulate in integer cents instead of floating point dollars to speed things up and make them more precise.

Prefer Doubles to Floats

I generally prefer doubles to floats because they are less likely to introduce rounding errors. The C++ compiler will often promote floats to doubles as it passes them to standard library functions even for calculations with basic operators. Using doubles generally makes your code and the compiler's generated machine code a little bit less complicated.

Rounding very frequently can become a concern, so you will need to consider conversions between integer and floating point, sequence of evaluation within equations, accumulated errors within loops, and normalization of very large and very small values when used together. You will wish to validate the ranges of both inputs and outputs, and sometimes intermediate values to insure things have not gone wrong.

Size Matters

To insure your results have precise values, you may need to understand the range and representation of the floating point types, and a little bit of numerical analysis. http://en.wikipedia.org/wiki/Floating_point has a lot of cool information.

As another down vote for floats in favor of doubles consider that a 32-bit float will burn eight bits for the exponent, and the mantissa part that holds a scaled version of your value will need to fit in 23 bits after you account for the sign of the mantissa. 2^23 is not particularly big. If you want to count from one to 10 million, you might want to use a 32 bit integer or a double.

Underlying architecture

If you have hardware floating point, generally it is OK to use it. If you don't, highly optimized libraries on fast clocked fix point processors may still cope very well.

If you have a eight bit embedded work horse, learn how to scale and normalize inputs and by all means, carefully implement your repetitious and time consuming calculations using fixed point. I am an Arduino documentation fan, even though my taste is to use beefier hardware when I work on embedded systems. The following link has a good discussion of what to do when your environment doesn't have native floating point and your compiler only gives you floats (but no doubles).


Many fixed point oriented architectures (for example, some Digital Signal Processors (DSP)) can help you with hardware instructions like multiply - accumulate, and often include very capable instructions to help multiply or do arithmetic shifts using integers. Details for using these may be performed by the compiler or by libraries, so it pays to learn as much as you can about your processor, particularly if you work on DSP or embedded projects.

  • I should also mention, that if you want to gain additional expertise, you should understand machine epsilon. en.wikipedia.org/wiki/Machine_epsilon Mar 15 '13 at 4:46
  • For graphics, it is often recommended to use doubles (if possible) for geometries, and floats for pixel values. This is because geometries often require more than 20 bits of significant figures, whereas human eyes and the computer displays they watch do not care much about 6-8 bits per color.
    – rwong
    Dec 17 '14 at 3:55
  • Also, the Wikipedia article on Loss of significance (floating point) is a recommended read for everyone who uses floating point, even if one is not interested in numerical processing.
    – rwong
    Dec 17 '14 at 3:57
  • Also: "Sometimes you can manipulate in integer cents instead of floating point dollars" - or tenths of cents, or for certain stock markets it may be better to use eighths of a cent. Don't limit yourself to thinking in whole base units: you can frequently find applications where an integer multiple of a fraction of a basic unit is the best representation.
    – Jules
    Dec 17 '14 at 8:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.