how PPC Cpu handle "double" and "float" in terms of speed

While porting some stuff from Pandora, have a question: how our PPCs handle "double" and "float" in terms of speed ? For example on ARM, float are much faster than double (especialy on old architecture like the cortex-a8 that equip the Pandora). What the case with our cpus ? Maybe there is some specific cpu options as well for GCC which can made things better for let's say x1000 and x5000 cpus ?

Double is faster! The CPU can only do double, so when dealing with floats it first needs to convert it internally.

I did some tests long ago on 603e and found that particular test to be like 5-10% faster with double, and that's with 32-bit memory bus!!

@kas1e
Roughly spoken: for the CPU it usually doesn't really matter too much if it's double or single precision you're using. Single precision values are converted to their double representation for internal use when (un)loaded into/from fpu registers, for free. What's not for free are explicit conversion commands.
On e.g. Tabor it's different, there the FPU internally distinguishes between single and double precision and also offers simple SIMD capabilities for 2 single precision values. AltiVec btw. wants single precision too.
For many commands you can specify whether to use single or double precision (e.g. fadd vs fadds). As far as I know some commands are a bit faster in single-precision mode.

Anyway, in real world you almost always want to follow this rule of thumb:
use the lowest precision required to do the task.

double precision puts twice the pressure on caches and memory, which is the main reason why using single precision most often results in (significant) higher performance on our systems.
I can definitely tell you: if you manage to kill your cache, your performance is gone, you won't get it back, simple as that - and the other way around: you can do tons of calculations on your data if you manage to have your stuff in the cache in time.
Therefore usually single precision floats are one of your best friends when it's about performance.

However, *don't* naively change a programs float / double usage unless you know exactly what you're doing. Although for example the avg. 3D game's vertex data and internal calculations are most often done with single precision data you shouldn't just blindly tell your compiler to compile everything for single prec! You may end up getting very subtle bugs.

The Vampire guys tapped into such an issue recently (which was fixed quickly). They gave their FPU a slightly too low internal precision (which is somewhat equivalent of telling your compiler to always use single prec). While most things worked, the timing of certain demos just went bogus depending on your system time: the demo would run fine if in the year 1970 and it would mess up when running in 2018, a phenomenon called "catastrophic cancellation", which may happen if you take two really big numbers which are close to each other, subtract the one by the other - and falsely expect the result to still have any sort of precision or value other than 0 With a bit more precision those calculations with those input values were okay again.

So, to sum it up:
- use single prec whenever you can for best performance because of cache/memory.
- use doubles when you have to.
- don't change the float / double behaviour of other people's code unless you know exactly what you're doing.

@Deniil
Are you sure that you really measured the right thing (e.g. not some explicit conversions) and a real-world situation (e.g. not just some tight loop with a fixed 32 byte dataset)? Because that's really not the result one would expect.

@Daniel
Thanks for detailed answer !
It is for game which while 3d based, pretty much depends on CPU than GPU, and while by default it builds with doubles , it has option (and tested with) to be build with floats. On ARM it give good extra boost, so probabaly should be ok for PPC as well then.

@kas1e
If the game has a well tested explicit single-prec-code-path, I strongly suggest: go for it

@Daniel
Btw, i just made a simple test:



And that what i have:

Quote:

Even about 25% speed up ?

@Deniil
Are you sure that on 603e you have double be faster on 5-10% than float ? Maybe its other way you mean, floats faster ?:)

@Daniel
And in game it give in end ~4fps more with floats :)

@kas1e
In your double function, you didn't cast the constants to double as you did in float function.
So I think there is an implicit conversion and this costs time.
Change your double function to
Rv += 2d/(i(i+2))
And see the difference with float function and old double function.

Interesting!

I also expected float to be faster, because of memory bandwidth mostly, but also cache in my algorithm and was surprized when double was faster.

I'll see if I can find those old test results again, and the algorithm. It was some audio processing routine of some sort.

Different CPUs are probably differently efficient on converting float<->double internally. Some may do it in zero cycles (while loading). Others need extra steps.