Re: Probably The Hardest Task I've Been Assigned At Seneca's CDoT (or at least the one that's taken me the longest...) rasp pi v6hl status

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM (Vger)]     [Linux ARM]     [ARM Kernel]     [Fedora User Discussion]     [Older Fedora Users Discussion]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

Powered by Linux