2010/7/12 Mark Mitchell mark@codesourcery.com:
Dave Martin wrote:
[...]
libm (if we're talking about the version in GLIBC) is many tiny source files, but many of them do not call one another.
From the user's point of view, it's not just code of this type that will benefit, but anything that calls it --- in practice that's going to be a larger set of software.
Yes, but it's still the case that those calls must be in an inner loop. For example, if your application calls "cos" in an inner loop, then this optimization might be important. (That depends on how many cycles "cos" takes to execute, but assuming "cos" takes only 100 cycles or so, then this is going to be important.)
Just in case there was confusion here, I didn't mean to imply that the cost of the function call from the application was likely to be significant, but rather that internal library function call overhead might account for a significant proportion of the execution time of the library function itself. If I call a function to transform 10000 3D points for example, that may well map to 10000 floating-point function calls inside a library - the ABI used to call from the application into the library is irrelevant in terms of cost, but the way the library is built can have a significant effect.
But I agree that we shouldn't expect to see a huge speedup unless we see it for real - and that there's plenty of reason to be sceptical about the chance of seeing large speedups for most software.
- Use ABI tagging (high effort, involving modifications to affected
projects - permits hardvfp ABI for explicitly selected functions)
- Build a fully hard-float world (high effort - requires packing and
distro work to define and build a new armelfp port of the archive)
Since (2) and (3) are both high-effort, perhaps it would be better to choose one of the other approach for now, rather than attempting to do both initially.
I agree. And, for what it's worth, I would try to avoid (3) at almost all costs. One of the advantages of the ARM ABI and one of the objectives of Linaro is to provide a standard platform. Life as a Linux ISV is complex enough (multiple distributions, kernel versions, etc.) without also having to worry about the ABI. I think it would be better to do quite a bit of tools work than to fall back to the approach of a completely parallel distribution.
Agreed, in general - if I get an opportunity to follow up with some numbers, but it may be a while before I can find the time to do anything on this...
Cheers ---Dave