Hi Guys,
Is it true that instructions execute faster in modern architecture if
the variables used for trig functions are doubles instead of floats?
And if so, why would that be?
Thanks
Hi Guys,
Is it true that instructions execute faster in modern architecture if
the variables used for trig functions are doubles instead of floats?
And if so, why would that be?
Thanks
Consider sin; it accepts an argument of the type double and returns a value of the type double, so if you pass a float and assign to a float, that's two type conversions your C implementation needs to perform. For most cases I'd say the time it takes to perform those conversions is negligible, but you can try using sinf if you find that calls to sin are slow.
Not true in general, regardless of whether an architecture is modern or not. It can be true, depending on the hardware design, and what it is optimised to achieve.
There are many factors other than performance of single instructions (multi-tiered memory architecture, instruction pipelining, speculative execution) that affect all types of system performance, including numerical performance.
The Cray-1 (a supercomputer delivered in the late 1970s) had native hardware support for double precision operations, and single-precision operations were emulated in software (therefore slower, despite consuming less memory).
Is there any problem that can result from changing every float declared in a program, and replacing it with doubles?
Assuming you haven't done anything fancy that accesses their bytes, etc.
Some of my program is (I think) Commodore 64 code which used only floats.
Why would you want to do that? If you're concerned about the performance of your code I suggest using a profiler like valgrind or gprof.
As far as C goes, assuming that's what you mean, 'double' is the default data type that's passed to math functions and printf, etc. So as was stated before, using 'float' saves only storage space but needs on-the-fly conversion to double when it's used.
What's actually faster in hardware is using 80-bit floats, which is native to the floating-point hardware internally. A hold-over from the co-processor days. However, C compilers do not generally support that data type for the programmer.
I don't see any problem changing every occurrence of 'float' to 'double' while porting code from Commodore. Be sure to check any formatting strings for input functions such as sscanf(), etc., so use %lf instead of %f to correctly interpret the value.
Thanks, I have ported the code long ago, but was just wondering if there's any nasties
to changing the variable types I might not know about. Doesn't hurt to try, but I don't
want anything going wrong with a distribution release.
You know you're getting desperate for optimisation when you sink to this!
I've sunk there. Done that!Originally Posted by xArt
You shouldn't expect the results to match exactly, for one thing.
Whether double or float is faster is a complicated issue. Such factors as rounding mode, space taken in cache, hardware support, and the level of strictness at which the compiler enforcing floating point rules can all come in to play. When fooling with this stuff in a shipping product, you had better have an extensive and trustworthy battery of tests.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Last I checked, in my software 3D engine, I found floats to still be marginally faster, but they did cause minor glitches due to the lesser precision in my case.
Note, I have not tried 64-bit code as yet.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
On certain x86 hardware and OS combinations, maybe. Even on systems using x87 code, it could still depend on whether the code is FPU bound or memory bound. And even taking that into account, using 80 bit values instead of doubles could prevent the compiler from doing various optimizations.
As others have said, if it's running slow, profile your code. Don't just guess.
