Double values store higher precision and are double the size of a float, but are Intel CPUs optimized for floats?
That is, are double operations just as fast or faster than float operations for +, -, *, and /?
Does the answer change for 64-bit architectures?
In experiments of adding 3.3 for 2000000000 times, results are:
Summation time in s: 2.82 summed value: 6.71089e+07 // float
Summation time in s: 2.78585 summed value: 6.6e+09 // double
Summation time in s: 2.76812 summed value: 6.6e+09 // long double
So double is faster and default in C and C++. It's more portable and the default across all C and C++ library functions. Alos double has significantly higher precision than float.
Even Stroustrup recommends double over float:
"The exact meaning of single-, double-, and extended-precision is implementation-defined. Choosing the right precision for a problem where the choice matters requires significant understanding of floating-point computation. If you don't have that understanding, get advice, take the time to learn, or use double and hope for the best."
Perhaps the only case where you should use float instead of double is on 64bit hardware with a modern gcc. Because float is smaller; double is 8 bytes and float is 4 bytes.
Alex Martelli's answer is good enough, but I want to mention a wrong but somewhat popular test method that may have misled some people:
#include <cstdio>
#include <ctime>
int main() {
const auto start_clock = clock();
float a = 0;
for (int i = 0; i < 256000000; i++) {
// bad latency benchmark that includes as much division as other operations
a += 0.11; // note the implicit conversions of a to double to match 0.11
a -= 0.13; // rather than 0.11f
a *= 0.17;
a /= 0.19;
}
printf("c++ float duration = %.3f\n",
(double)(clock() - start_clock) / CLOCKS_PER_SEC);
printf("%.3f\n", a);
return 0;
}
It's wrong! C++ default use double, if you replace += 0.11 by += 0.11f, float will usually be faster then double, on x86 CPU.
By the way, on modern SSE instruction set, both float and double have same speed except of division operation, in the CPU core itself. float being smaller may have fewer cache misses if you have arrays of them.
And if the compiler can auto-vectorize, float vectors work on twice as many elements per instruction as double.
In addition some real data of a benchmark to get a glimpse:
For Intel 3770k, GCC 9.3.0 -O2 [3]
Run on (8 X 3503 MHz CPU s)
CPU Caches:
L1 Data 32 KiB (x4)
L1 Instruction 32 KiB (x4)
L2 Unified 256 KiB (x4)
L3 Unified 8192 KiB (x1)
--------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------
BM_FloatCreation 0.281 ns 0.281 ns 1000000000
BM_DoubleCreation 0.284 ns 0.281 ns 1000000000
BM_Vector3FCopy 0.558 ns 0.562 ns 1000000000
BM_Vector3DCopy 5.61 ns 5.62 ns 100000000
BM_Vector3F_CopyDefault 0.560 ns 0.546 ns 1000000000
BM_Vector3D_CopyDefault 5.57 ns 5.56 ns 112178768
BM_Vector3F_Copy123 0.841 ns 0.817 ns 897430145
BM_Vector3D_Copy123 5.59 ns 5.42 ns 112178768
BM_Vector3F_Add 0.841 ns 0.834 ns 897430145
BM_Vector3D_Add 5.59 ns 5.46 ns 100000000
BM_Vector3F_Mul 0.842 ns 0.782 ns 897430145
BM_Vector3D_Mul 5.60 ns 5.56 ns 112178768
BM_Vector3F_Compare 0.840 ns 0.800 ns 897430145
BM_Vector3D_Compare 5.61 ns 5.62 ns 100000000
BM_Vector3F_ARRAY_ADD 3.25 ns 3.29 ns 213673844
BM_Vector3D_ARRAY_ADD 3.13 ns 3.06 ns 224357536
where operations on 3 float(F) or 3 double(D) are compared and - BM_Vector3XCopy is the pure copy of a (1,2,3) initialized vector not repeated before copy, - BM_Vector3X_CopyDefault with default initialization repeated every copy, - BM_Vector3X_Copy123 with repeated initialization of (1,2,3),
Compare Checks for equality of two initialized vectors,
ARRAY_ADD Sums up vector(1,2,3) + vector(3,4,5) + vector(6,7,8) via std::valarray what in my case leads to SSE instructions.
Remember that these are isolated tests and the results differ with compiler settings, from machine to machine or architecture to architecture. With caching (issues) and real world use-cases this may be completely different. So the theory can greatly differ from reality. The only way to find out is a practical test such as with google-benchmark[1] and checking the result of the compiler output for your particular problem solution[2].