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?
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).