I'm writing an application which reads large arrays of floats and performs some simple operations with them. I'm using floats, because I thought it'd be faster than doubles, but after doing some research I've found that there's some confusion about this topic. Can anyone elaborate on this?
10 Answers
The short answer is, "use whichever precision is required for acceptable results."
Your one guarantee is that operations performed on floating point data are done in at least the highest precision member of the expression. So multiplying two float's is done with at least the precision of float, and multiplying a float and a double would be done with at least double precision. The standard states that "[floating-point] operations may be performed with higher precision than the result type of the operation."
Given that the JIT for .NET attempts to leave your floating point operations in the precision requested, we can take a look at documentation from Intel for speeding up our operations. On the Intel platform your floating point operations may be done in an intermediate precision of 80 bits, and converted down to the precision requested.
From Intel's guide to C++ Floating-point Operations1 (sorry only have dead tree), they mention:
- Use a single precision type (for example, float) unless the extra precision obtained through double or long double is required. Greater precision types increase memory size and bandwidth requirements. ...
- Avoid mixed data type arithmetic expressions
That last point is important as you can slow yourself down with unnecessary casts to/from float and double, which result in JIT'd code which requests the x87 to cast away from its 80-bit intermediate format in between operations!
1. Yes, it says C++, but the C# standard plus knowledge of the CLR lets us know the information for C++ should be applicable in this instance.

- 30,738
- 21
- 105
- 131

- 63,008
- 17
- 141
- 172
-
3On a side note (with no bearing on your answer), does the .net JIT use x87? Intel's been telling everyone to abandon it for a while in favour of SSE. – Oct 01 '08 at 18:34
-
2@Mike F: from what I can tell, it doesn't appear to choose SSE operations. Don't quote me on that, that is only from what I've seen JIT'd in my code. I may ask a microsoftie and find out. – user7116 Oct 01 '08 at 18:35
-
@sixlettervariables: I'd be very interested to hear the answer if you ever get one and feel like posting it here. – Oct 01 '08 at 18:43
-
I recall seeing an x86 JIT team member explain their logic on this. He said that they use x87 for floating point, not SSE, as SSE is faster for some operations and slower for others. As the JIT does not attempt to vectorize floating point math, they opted to make a really good x87 JIT rather than split their efforts. – Eloff Jul 23 '10 at 20:43
-
I managed to track down the reference, it's David Notario in this discussion for those interested, but it is about the JIT in 1.1, so treat it with great suspicion: http://bytes.com/topic/c-sharp/answers/224459-sse-mmx-support-jit-compiler – Eloff Jul 23 '10 at 20:50
-
1I agree the instruction on float, double, integer, short and char or even 1 bit takes one CPU cycle disregarding the type. But does a difference arise if you consider comparison of addressing, locality, parallel processing. It seems to me that double precision processing has more overhead. It is not very easy to do real test. Compilers are smart and optimize overhead so the real issue can stay hidden if the test doing relatively dumb work. – DeveloperInToronto May 20 '11 at 18:38
-
1@DeveloperInToronto: Many floating-point operations require multiple cycles. And so do a few integer operations. Also, the baseline for comparison isn't even "1 cycle", but a fraction, since modern CPUs have multiple ALUs. – Ben Voigt Jan 04 '13 at 14:38
I just read the "Microsoft .NET Framework-Application Development Foundation 2nd" for the MCTS exam 70-536 and there is a note on page 4 (chapter 1):
NOTE Optimizing performance with built-in types
The runtime optimizes the performance of 32-bit integer types (Int32 and UInt32), so use those types for counters and other frequently accessed integral variables. For floating-point operations, Double is the most efficient type because those operations are optimized by hardware.
It's written by Tony Northrup. I don't know if he's an authority or not, but I would expect that the official book for the .NET exam should carry some weight. It is of course not a gaurantee. I just thought I'd add it to this discussion.

- 6,530
- 8
- 60
- 103
I profiled a similar question a few weeks ago. The bottom line is that for x86 hardware, there is no significant difference in the performance of floats versus doubles unless you become memory bound, or you start running into cache issue. In that case floats will generally have the advantage because they are smaller.
Current Intel CPUs perform all floating point operations in 80 bit wide registers so the actual speed of the computation shouldn't vary between floats and doubles.

- 634
- 3
- 4
I'm writing a ray tracer, and replacing the floats with doubles for my Color class gives me a 5% speedup. Replacing the Vectors floats with doubles is another 5% faster! Pretty cool :)
That's with a Core i7 920
-
1I would guess due to some of your code casting backwards and forwards between float->double->float, e.g. with maths functions that return double, so eliminating the casting is responsible for the speed up; not necessarily because doubles are innately faster. – HoboBen Oct 11 '10 at 06:11
-
9Actually, I take that back. I just tested with a simple for loop, and it seems, for whatever reason, doubles *are* faster! – HoboBen Oct 11 '10 at 09:15
-
1The processor is irrelevant. Whether you do this on a slow or fast PC... a 5% improvement is a 5% improvement :-) – z0mbi3 Oct 15 '15 at 21:46
If load & store operations are the bottleneck, then floats will be faster, because they're smaller. If you're doing a significant number of calculations between loads and stores, it should be about equal.
Someone else mentioned avoiding conversions between float & double, and calculations that use operands of both types. That's good advice, and if you use any math library functions that return doubles (for example), then keeping everything as doubles will be faster.

- 19,598
- 4
- 47
- 69
-
2This is the case with C# where all math operations return doubles. For literal values, you can use f, etc for the value itself. – Joan Venge Jan 06 '09 at 18:56
With 387 FPU arithmetic, float is only faster than double for certain long iterative operations like pow, log, etc (and only if the compiler sets the FPU control word appropriately).
With packed SSE arithmetic, it makes a big difference though.

- 7,941
- 4
- 26
- 38
You are wrong. 32-bit is far more efficient than 16-bit - in modern processors... Perhaps not memory-wise, but in effectiveness 32-bit is the way to go.
You really should update your professor to something more "up-to-date". ;)
Anyway, to answer the question; float and double has exactly the same performance, at least on my Intel i7 870 (as in theory).
Here are my measurements:
(I made an "algorithm" that I repeated for 10,000,000 times, and then repeated that for 300 times, and out of that I made a average.)
double
-----------------------------
1 core = 990 ms
4 cores = 340 ms
6 cores = 282 ms
8 cores = 250 ms
float
-----------------------------
1 core = 992 ms
4 cores = 340 ms
6 cores = 282 ms
8 cores = 250 ms

- 30,738
- 21
- 105
- 131

- 49
- 1
- 1
-
Hmm, I guess you are right. Maybe the source that led me to believe the question was wrong was wrong. I will update my answer to remove the update (i.a.w. un-update my answer). – Matthijs Wessels Feb 28 '11 at 08:20
I have always thought that the processors were optimized or the same regardless of float or double. Searching for optimizations on my intensive computations (lots of gets from a matrix, comparisons of two values) I found out that floats run about 13% faster.
This surprised me, but I guess it is due to the nature of my problem. I don't do casts between float and double in the core of the operations, and my computations are mainly adding, multiplying and subtracting.
This is on my i7 920, running a 64-bit operating system.

- 30,738
- 21
- 105
- 131

- 5,132
- 8
- 41
- 51
This indicates that floats are slightly faster than doubles: http://www.herongyang.com/cs_b/performance.html
In general, any time you do a comparison on performance, you should take into account any special cases, like does using one type require additional conversions or data massaging? Those add up and can belie generic benchmarks like this.

- 13,085
- 9
- 62
- 89
-
2I don't know if I'd trust some dude's benchmarks where the precision is coming down to less than a second. Why not write a bigger (and more real-world-ish benchmark with more different types of tests) and let it run for several minutes? – Nik Reiman Oct 01 '08 at 18:30
-
I tried this test and in Release build, they take the same processing time. – Joan Venge Jan 06 '09 at 18:59
Floats should be faster on a 32-bit system, but profile the code to make sure you're optimizing the right thing.

- 30,738
- 21
- 105
- 131

- 60,273
- 18
- 132
- 202
-
3@Steven A. Lowe: I would note that some 32-bit systems lack 32-bit floating point numbers internally! Hence, decreasing overall performance. Your statement is correct from a memory-bandwidth perspective as a float fits nicer than a double. – user7116 Oct 01 '08 at 18:16