Hey Dave
Great to have you back!
On Fri, Jul 09, 2010, Dave Martin wrote:
Regarding this discussion, I stongly advocate getting some benchmarks --- we should be careful about drawing conclusions like "won't be much of a win on A9" without some quantification.
+1; this is just from hearsay so far.
Would you be in a position to do them?
Markos has the karmic rebuild of armel with hard-float ABI + sources. There are some rootfses up there as well. I will share the link with you off-list since I'm not sure it's ok to advertize it wildly.
For all v7 processors (A8, A9, etc.) the hardfp ABI will increase the register bandwidth for funtion calls. In some cases of floating-point intensive code, the increase will be substantial.
Yes; I agree, in any case, the hard-floating point will be superior, we don't know how much. What I meant to express is that Linaro didn't go for a hardfp port because the wins weren't obvious over the (large) time investment + maintenance commitment, and it seemed that by the time we would get there, Cortex-A9s would be common and the wins would be limited.
Now if we were to have benchmarks, the story might be entirely different indeed.
One particular issue we have is that the toolchain cannot easily handle intermixing of multiple ABIs, so it isn't straightforward to use a different ABI (hard) internally to a library or shared object compared with the ABI (softfp) used at the public interface. This means that some libs which may get significant benefit from the hard fp ABI to accelerate internal function calls (such as libm, as well as any computational library) cannot be built using the hard fp ABI internally without doing significant work, unless the whole system is built with hard fp. It's certainly not something we can achieve by simply using dififerent build options for targeted libraries, as can be done for NEON optimisations for example.
I think we either have a Debian (and an Ubuntu) hard-float port or we don't; once we have it, everything is available with hard-float, and we will probably shift our focus on that. If the cost is too high, then we will stay with the armel port and try to rip the most benefits out of it, building vfp versions of the libs (softfp). Perhaps we need to fix the toolchain to be more agressive in softfp mode (especially when combined with -Bsymbolic-functions), or perhaps we need to rework key libraries to use hardfp but keep a soft-float interface as you say.
Judging how much these changes will improve the performance of real-world code, and how the improvement compares on A9 versus A8, is difficult without doing some benchmarking though.
You speak the truth! Thanks a lot for your comments