Are doubles faster than floats in C#?
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?
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.
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.
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.
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.
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
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.
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
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.
Floats should be faster on a 32-bit system, but profile the code to make sure you're optimizing the right thing.
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.
ReferenceURL : https://stackoverflow.com/questions/158889/are-doubles-faster-than-floats-in-c
'programing' 카테고리의 다른 글
Conditional with statement in Python (0) | 2021.01.17 |
---|---|
Keep Text From Wrapping in Bootstrap 3 Responsive Design (0) | 2021.01.17 |
xna에서 창 / 화면 크기를 어떻게 설정합니까? (0) | 2021.01.17 |
PHP에서 가중치로 무작위 결과를 생성합니까? (0) | 2021.01.16 |
ASP.Net RadioButton 및 CheckBox가 Span 내부에서 렌더링되는 이유는 무엇입니까? (0) | 2021.01.16 |