Re: armelfp: new architecture name for an armel variant
On 7/11/10, Bill Gatliff <bgat@billgatliff.com> wrote:
> But then doesn't that mean that everything is "armel", so we never have a
> hope of having Debian officially support more than one combination?
Well, "armel" should be as generic as possible. In an ideal world, it
would be called "arm" and run on pretty much all ARM processors. After
all, Debian's tagline is "The Universal Operating System", while
cpu-specific tweaking is the speciality of Gentoo, OpenEmbedded and so
on.
But, since "arm" was already taken, and it used emulated hardfloat
instructions instead of softfloat, the main advantage of facing the
pain and embarassment of a new port was that it would make FP 11 times
faster on all ARM CPUs, as well as permitting use of real FPUs, making
it 30 or 40 times faster. That's the difference between encoding a
30-second MP3 in a minute or encoding it in 2 seconds.
The argument in favour of yet another ARM Debian arch (making four so
far) is the figure of another 30% being waved about. Not another
factor of 30, just another 30%, and presumably that figure comes from
beating some worst-case situation to death. Actual figures would be
nice.
> I'm ok with that, actually--- an ecosystem of unofficial "armel"
> repositories cropping up containing optimized packages for specific
> configurations.
Yes. That is the right way to go to leverage FPUs in the Debian
framework, and was one of the justifications for the upheavals that
the "armel" port caused.
Where does this "30%" figure that's been floated around for hardfloat
ABI over softfloat ABI with VFP instructions come from? Do we have any
actual measurements?
Wanting to politick a fourth Debian ARM architecture into dpkg, with
all the work that involves for other people, just to get a few percent
speed increase in a few packages doesn't seem worth doing. You can
get a 3 or 4 times speed increase with an FPU-specific armel
repository, which is a mechanism well suited to supporting specific
combinations.
It doesn't seem worth causing all that pain again just to get an
extra 30% of frames per second in glgears. It's an optimization, yes,
but look at the cost.
M
Reply to: