More floating point performance using hard floats


It has a simple scalar single and double precision FP instruction unit, VFP. From what I could gather it's pretty useless, though. People say than on a Cortex-A8 the only way to get a good FP performance is to use NEON, it's just that NEON only does single precision FP math and IIRC GCC isn't very good at generating NEON code.


As the Cortex-A8's VFP is not pipelined and shares its registers with NEON, it could be affected by some of NEON's other drawbacks as well, I guess.
 
It has a simple scalar single and double precision FP instruction unit, VFP. From what I could gather it's pretty useless, though. People say than on a Cortex-A8 the only way to get a good FP performance is to use NEON, it's just that NEON only does single precision FP math and IIRC GCC isn't very good at generating NEON code.


As the Cortex-A8's VFP is not pipelined and shares its registers with NEON, it could be affected by some of NEON's other drawbacks as well, I guess.

I dunno about that - my code used soft-floats and was quite slow. When I rebuilt with VFPv3, I got a very respectable speed boost, in the region of 200-300%. My next goal is to build with NEON, as that is (according to those in the know) a superset of VFP, which should give a much better speed boost.


D.
 
Sony, if you can merge it so that the posts still make sense in the other thread, go ahead. If you can't, lock this one up.
 
VFP. From what I could gather it's pretty useless, though. People say than on a Cortex-A8 the only way to get a good FP performance is to use NEON

I dunno about that - my code used soft-floats and was quite slow. When I rebuilt with VFPv3, I got a very respectable speed boost, in the region of 200-300%. My next goal is to build with NEON, as that is (according to those in the know) a superset of VFP, which should give a much better speed boost.


D.

I think what Letalis refers to is the fact VFP and NEON on ARM cortex A8 are known to achieve 10% perfs (in floating point benchmarks) of current generation Atoms, who already suck big time as they are the equals of 2005 era Celerons. So compared with the modern x86 processor you probably have in your PC, ARMs don't even register. Cortex A9 are said to level up with the Atoms though. Nonetheless floating points calculations are best avoided on arm if you seek performance... Integer perfs/power consumption ratios are on par with modern x86 even in Cortex A8.


This comparison doesn't mean using VFP instead of soft-float isn't much faster. Hard FPU are always a lot faster than soft libraries based on integer instructions :)


The only drawback of Neon I know of, is that the instruction set is single point. Also, I don't know what exists to program with NEON unit in Linux ? I've only done such vector calculations on DSP where all you have are the asm macros of C, or a few C wrappers for the assembler instructions. Most of the time for raw performance you have to use inline asm, as C code output by compiler can't really achieve the same number of instructions.
 
Last edited by a moderator:
You cannot sell any x86 CPU without a full fledged FPU anymore. But those chips are massive, they are taking up by far the most place on the die while being rather useless most of the time. That's the reason AMD went with a 2+1 design for their upcoming architecture, those full FPUs are idling most of the time and even when extensively used they can hardly show off their full potential, so why not combining one FPU with 2 integer cores?


With lots of silicon comes lots of Watts. It's absolutely reasonable to omit an FPU to save energy on ARM, usually a good FP performance is rarely needed and software emulation absolutely fills the few missing holes without being too much of a brick on your leg. VFP and NEON are very specialised units, they can't be compared with a full fledged x86 FPU. They can be much slower with common FP math than what you might be used to from a full FPU, simply because the problem to solve (or its implementation) does not fit very well to the unit's available instructions - especially when the compilers are bad at generating code for those units, making hand crafted assembler code the only option for a good performance.
 
Just to be complete, the benchmarks I'm refering to were made in assembly (no need comparing output of compilers) doing simple FIR filters -like calculations (which should fit well for a vectorial FP instruction set like NEON).


BTW I tought the thing taking the more space in silicon was the cache ?
 
Well, except the caches, I thought that was kind of implied (yeah, don't drink and post :p ).


Anyway, the cache/FPU size proportions have shifted a lot in the last years as it seems, I have seen a pic of a first-gen Phenom X4 where the FPU was about the same size as its 512KiB L2 cache and I have seen a pic of an old Athlon where the FPU fits 3 times into the space taken up by the same amount of L2 cache.
 
Back
Top