Float or Double?

Which is faster, double or flo开发者_如何转开发at, when preforming arithimic (+-*/%), and is it worth just using float for memory reasons? Precision is not an issue much of an issue.

Feel free to call me crazy for even thinking this. Just curious as I see the amount of floats I'm using is getting larger.

EDIT 1: The only reason this is under android is because that is where I believe memory matters; I wouldn't even ask this for desktop development.

The processing speed on both types should approximately be the same in CPUs nowadays.

"use whichever precision is required for acceptable results."

Related questions have been asked a couple of times here on SO, here is one.

Edit:

In speed terms, there's no difference between float and double on the more modern hardware.

Please check out this article from developer.android.com.

Double rather than Float was advised by ADT v21 lint message due to the JIT (Just In Time) optimizations in Dalvik from Froyo onwards (API 8 and later).

I was using FloatMath.sin and it suggested Math.sin instead with the following under "explain issue" context menu. It reads to me like a general message relating to double vs float and not just trig related.

"In older versions of Android, using android.util.FloatMath was recommended for performance reasons when operating on floats. However, on modern hardware doubles are just as fast as float (though they take more memory), and in recent versions of Android, FloatMath is actually slower than using java.lang.Math due to the way the JIT optimizes java.lang.Math. Therefore, you should use Math instead of FloatMath if you are only targeting Froyo and above."

Hope this helps.

I wouldn't advise either for fast operations but I would believe that a operations on floats would be faster as they are 32 bit vs 64 bit in doubles.

http://developer.android.com/training/articles/perf-tips.html#AvoidFloat

Avoid Using Floating-Point

As a rule of thumb, floating-point is about 2x slower than integer on Android-powered devices.

In speed terms, there's no difference between float and double on the more modern hardware. Space-wise, double is 2x larger. As with desktop machines, assuming space isn't an issue, you should prefer double to float.

Also, even for integers, some processors have hardware multiply but lack hardware divide. In such cases, integer division and modulus operations are performed in software—something to think about if you're designing a hash table or doing lots of math.

a float is 32 bits or 4 bytes

a double is 64 bits or 8 bytes

so yeah, floats are half the size according to the sun java certification book.

In speed terms, there's no difference between float and double on the more modern hardware.

Very cheap devices seem to have a limited FPU where float is faster than double. I tested on a CMX device that is currently marketed as one of the the cheapest tablets in the world:

• "float" test code takes 4.7 seconds
• same code with "double" takes 6.6 seconds

This question has been asked a couple of times ...

Yes. Because the answer differs for different types of hardware. On desktop computers double has the same speed as float. On devices without FPU (interesting for WLAN router hacks) float is 2-5 times faster than double; and on devices with 32-bit FPU (often found in industrial and automotive applications) even up to 100 times.

Please check out this article ...

The last section of the article says that you have to do time measurements on the hardware device you are going to use to be 100% sure.

The android documentation quoted indicates that integers are preferable for fast operations. This seems a little strange on the face of it but the speed of an algorithm using ints vs floats vs doubles depends on several layers:

1. The JIT or VM: these will convert the mathematical operations to the host machine's native instruction set and that translation can have a large impact on performance. Since the underlying hardware can vary dramatically from platform to platform, it can be very difficult to write a VM or JIT that will emit optimal code in all cases. It is probably still best to use the JIT/VM's recommended fast type (in this case, integers) because, as the JITs and VMs get better at emitting more efficient native instructions, your high-level code should get the associated performance boosts without any modification.

2. The native hardware (why the first level isn't perfect): most processors nowadays have hardware floating point units (those support floats and doubles). If such a hardware unit is present, floats/doubles can be faster than integers, unless there is also hardware integer support. Compounding the issue is that most CPUs have some form of SIMD (Single Instruction Multiple Data) support that allow operations to be vectorized if the data types are small enough (eg. adding 4 floats in one instruction by putting two in each register instead of having to use one whole register for each of 4 doubles). This can allow data types that use fewer bits to be processed much faster than a double, at the expense of precision.

Optimizing for speed requires detailed knowledge of both of these levels and how they interact. Even optimizing for memory use can be tricky because the VM can choose to represent your data in a larger footprint for other reasons: a float may occupy 8 bytes in the VM's code, though that is less likely. All of this makes optimization almost the antithesis of portability. So here again, it is better to use the VM's recommended "fast" data type because that should result in the best performance averaged across supported devices.

This is not a bad question at all, even on desktops. Yes they are very fast today, but if you are implementing a complicated algorithm (for example, the fast Fourier transform), even small optimizations can have an enormous impact on the algorithm's run time. In any case, the answer to your question "which is faster: floats or doubles" is "it depends" :)

I wondered about this too and wrote a small test:

#include <iostream>
#include <chrono>

template<typename numType>
void test(void)  {
    std::cout<< "Size of variable: " << sizeof(numType) << std::endl;
    numType array[20000];

    auto t1 = std::chrono::high_resolution_clock::now();
    // fill array
    for( numType& number : array ) {
        number = 1.0014535;
    }

    auto t2 = std::chrono::high_resolution_clock::now();

    // multiply each number with itself 10.000 times
    for( numType& number : array ) {
        for( int i=0; i < 10000 ; i++ )  {
            number *= number;
        }
    }

    auto t3 = std::chrono::high_resolution_clock::now();

    auto filltime = t2 - t1;
    auto calctime = t3 - t2;

    std::cout<< "Fill time: " << filltime.count() << std::endl;
    std::cout<< "Calc time: " << calctime.count() << std::endl;
}

int main(int argc, char* argv[]) {
    test<float>();
    test<double>();
}

I ran and compiled it under Ubuntu 12.04 x64 using GCC on an Intel i7 3930k processor

These were the results:

Size of variable: 4
Fill time: 69
Calc time: 694303

Size of variable: 8
Fill time: 76
Calc time: 693363

Results were reproducable. So memory allocation for double takes slightly longer but the actual calculation time is exactly the same.

Out of curiousity I also ran and compiled it under Windows 7 x64 using Visual Studio 2012 in release mode on an intel i7 920 processor

(The unit of the time is different so don't compare the results above to these: it is only valid for internal comparison)

Size of variable: 4
Fill time: 0
Calc time: 3200183

Size of variable: 8
Fill time: 0
Calc time: 3890223

Results were reproducable.

It seems on windows allocation is instant, perhaps because linux does not actually give you memory until you use it while windows just hands it all over to you at once, requiring less system calls. Or perhaps the assignment is optimized away.

The multiplication of doubles is 21,5% slower here than for floats. This difference with the previous test is likely due to the different processor (that's my best guess at least).