It raises a couple of questions, though.
1) How much performance difference does this _actually_ make over armv5tel
targeted binaries? The benchmark results I have seen from a similar Debian
effort is that with the exception of A/V transcoding, the performnce
difference is in the low single figure % points which is unlikely to be
perceivable over and above the placebo effect to the average user.
From my understanding of the Raspian graphs you see around the place
it's a comparison of Debian 6 vanilla to a custom compiled Wheezy.
Debian 6 for ARM was compiled for ARMv4t chips as opposed to a ARMv6hl
build. I think you'd cover off a chunk of the performance differences
in the move from v4t to v5tel. Add to that the massive amounts of work
that has been done of late on a lot of libraries to optimise them for
arm (linpng, libjepg, pixman, cairo etc etc) between the versions
shipped for the different releases and I think you would almost be
there without v6hl optimisations.
2) Why base the mainline distribution on armv7hl instead of armv6hl
if
armv6hl code will run on both? (Note: I don't consider the argument of
"That's what all the other distros are doing." to stand up on it's own
at
face value.)
There's a number of reasons for going with v7hl over v6hl.
1) There was no v6 boards around when we made the decision. Most of
the v6 chips are used in cheap low end phones of which we're not
targeting what so ever as a Fedora device. Since that decision there
is now 2. The Pi and a VIA board.
2) There's quite a bit of architectural difference and optimisations
between v6 and v7 that make it worthwhile optimising v7 on it's own.
This includes a completely different completely rearchitected VFP It's
also where all chips are going even on the very low end.
3) Most of the features in v6 were optional in v5 and hence were run
time detectable anyway
4) Prior to gcc 4.7 there were apparently issues with the VFP2
implementation and it hadn't been widely used as far as we could tell,
the optimisation that had gone into hardfp in gcc 4.[5-7] were mostly
aimed at the VFPv3 in the ARMv7+ processors. VFPv2 in the armv6 still
isn't compulsory.
5) That's the direction where the industry was going (and hence all
the distros) and so we also went where the industry was going to
ensure as much compatibility moving forward for binaries between the
various distros as possible. Compiling for VFPv2+ wasn't going to give
us that.
Basically it was a whole lot of pain for at the time of the decision
zero gain. Even now I don't think it's worth the effort and we still
don't have solid numbers to prove it either way.
Peter