Here is a very thorough and complete list of benchmarks comparing softfp (Ubuntu armel) and hard (Debian armhf) ABIs, made for Linaro:

https://wiki.linaro.org/OfficeofCTO/Har ... Benchmarks

Notice especially the POVRay and GtkPerf ones! :)

Also, we're working on benchmarking real 3D performance (using recompiled 3D drivers for armhf and comparing), so far the gain from going with hardfloat is between 10-20% on average.

If you have any suggestions of what else might be good to benchmark, feel free to say so :)

The results are certainly interesting. Out of curiosity are these compiled for VFPv3 or for NEON?
How do the linaro hardfp binaries relate to the hardfp support in ubuntu binaries?

VFPv3. Right now there are no Ubuntu or Linaro hardfp binaries. As stated the hardfp binaries used are from the Debian armhf port.

Let's clarify again what "hardfp" actually is as I think this is a source of some confusion.

The most recent ARM AAPCS ABI has two basic working modes; standard and "VFP" mode. Standard has basically two subsets - emulated and hardware floating point. VFP mode is also hardware floating point.

The difference is mainly that a binary compiled with "soft" or "softfp" is using the standard ABI where all floating point arguments are passed in the standard ARM register file (r0-r3) which means that if the function has emulated floating point OR hardware floating point, but in the case of hardware floating point the data has to be copied to the real FPU first which is somewhat of a performance hit (it incurs a 20-cycle pipeline stall and flush while the data is copied to the FPU register file, compilers do reschedule the copies to try and hide it but sometimes it's not possible to get rid of that much waiting time). It also impacts code density.

The VFP variant is what we call "hardfp" which puts floating point arguments in the floating point register file (s0 or d0 and onwards). On a chip with no VFP unit doing this would cause a coprocessor exception. They are also mutually incompatible with the standard ABI where floating point arguments are involved (but an app that ONLY uses integer arguments would work just fine, it's unsafe to assume this just from the binary object header though).

Essentially Debian armel uses soft (forcing emulation), Ubuntu has used soft in Jaunty and softfp in Karmic (optional hardware floating point with incurred penalties as above) and only Debian armhf has hardfp (no penalties except that it will not work with no FPU and requires a certain base level of CPU) enabled right now but Android and Ubuntu may have it in the future (this time next year maybe).

_________________
Matt Sealey

There is a slight typo in the first table:
TI Omap4 (Cortex-A8)
should be:
TI Omap4 (Cortex-A9)

(it's clear from later tables that it's Cortex-A9)

Thanks for the benchmarks!