views:

4869

answers:

3

I did some timing tests and also read some articles like this one (last comment),and it looks like in Release build, float and double values take the same amount of processing time.

How is this possible? When float is less precise and smaller compared to double values, how can the CLR get doubles into the same processing time?


Edit:

Exact duplicate of "Are doubles faster than floats in c"

+22  A: 

On x86 processors, at least, float and double will each be converted to a 10-byte real by the FPU for processing. The FPU doesn't have separate processing units for the different floating-point types it supports.

The age-old advice that float is faster than double applied 100 years ago when most CPUs didn't have built-in FPUs (and few people had separate FPU chips), so most floating-point manipulation was done in software. On these machines (which were powered by steam generated by the lava pits), it was faster to use floats. Now the only real benefit to floats is that they take up less space (which only matters if you have millions of them).

P Daddy
Perhaps not 100 years ago... Some FPUs support native handling at float, double, and 80-bit levels and will execute faster at the shorter lengths. Some will actually execute some things slower at shorter lengths too... :-)
Brian Knoblauch
Possible exception: I think the time for divisions is dependent on the number of bits (1 clock cycle/2 bits). Timings I've made of float vs double division seem to tally with this.
Neil Coffey
Caveat for SIMD code - since you can pack 2x floats than doubles into a SIMD register (e.g. SSE), potentially operating on floats could be faster.But since it's C#, that's likely not going to happen.
Calyth
Why it's not likely to happen in C#? You mean currently or ever?
Joan Venge
Unless mono's SIMD extensions goes in MS' .net. Which is practically... never.
artificialidiot
I'm not sure, but some compilers may cast floats to doubles and back again, generating extra instructions. BTW once I debugged a FP library. Just to add 2 IEEE floating point numbers took ~300 instructions, it has to unpack to 80 bits, normalize, check for NaNs, and undo all that and incidentally add somewhere in the middle. I'm sure FP processors have hardware help, but they still have to do all these things.
Mike Dunlavey
+1  A: 

There are still some cases where floats are prefered however - with OpenGL coding for example it's far more common to use the GLFloat datatype (generally mapped directly to 16 bit float) as it is more efficient on most GPU's than GLDouble

Cruachan
Why is this the case?
Malfist
Good question =)
Maybe due to higher data throughput? If you have a matrix of numbers (z-buffer etc.), the data size becomes more important, and avoiding conversions between float and double speeds up handling. My guess.
Lucero
Undoubtedly throughput. Also given the specialised context there is unlikely anything visible to be gained from using doubles over floats so why waste the memory - especially as it is in shorter supply on GPUs than CPUs
Cruachan
+3  A: 

I had a small project where I used CUDA and I can remember that float was faster than double there, too. For once the traffic between Host and Device is lower (Host is the CPU and the "normal" RAM and Device is the GPU and the corresponding RAM there). But even if the data resides on the Device all the time it's slower. I think I read somewhere that this has changed recently or is supposed to change with the next generation, but I'm not sure.

So it seems that the GPU simply can't handle double precision natively in thous cases, which would also explain why GLFloat is usually used rather than GLDouble.

(as I said it's only as far as I can remember, just stumbled upon this while searching for float vs. double in a CPU context)

Mene