Go back to Richel Bilderbeek's homepage.
Go back to Richel Bilderbeek's C++ page.
Will it pay off to replace the use of doubles by a custom class using integers? is an FAQ about the expected gains of replacing floating point (that is double) calculations by using a custom class that uses integers to emulate a floating point.
I posted the original question here.
Thanks to MiiNiPaa for his answer:
No |
Additionally, MiiNiPaa replied with a link to stackoverflow.com. The reactions varied from repeating that in general integer operations are faster than floating point math. stephen canon supplied a link to agner.com, of which the article 'Optimizing software in C++: An optimization guide for Windows, Linux and Mac platforms' gives many pinpointers. For example, it states for integers (section 'Integer operators',page 30):
Integer operations are generally very fast. Simple integer operations such as addition, subtraction, comparison, bit operations and shift operations take only one clock cycle on most microprocessors. |
And for doubles (section 'Floating point variables and operators',page 32):
Floating point addition takes 3 - 6 clock cycles, depending on the microprocessor.
Multiplication takes 4 - 8 clock cycles. Division takes 14 - 45 clock cycles. |
This makes me conclude that int is faster for simpler (addition, comparison) operations only.
Note that the conversion between integer and double is especially costly, as agner.com the article 'Optimizing software in C++: An optimization guide for Windows, Linux and Mac platforms' states (section 'Float to integer conversion',page 41):
Conversion of a floating point number to an integer takes a very long time unless the SSE2 or later instruction set is enabled. Typically, the conversion takes 50 - 100 clock cycles. |
Back to the original question: Will it pay off to replace the use of doubles by a custom class using integers?
As such a custom class uses two integers, my guess will be: no.
To draw a conclusion, use a profiler.
Go back to Richel Bilderbeek's C++ page.
Go back to Richel Bilderbeek's homepage.
This page has been created by the tool CodeToHtml