Bug#736752: speex: Please enable floating point for armhf

[Ron]

On Wed, Jan 29, 2014 at 06:27:27PM +0000, Steve Langasek wrote:
> On Wed, Jan 29, 2014 at 07:25:30AM +1030, Ron wrote:
> > On Sun, Jan 26, 2014 at 09:36:28AM +0000, Steve Langasek wrote:
> 
> > > The speex package in Debian currently does a fixed point build, instead of
> > > a floating point build, on all architectures where $DEB_HOST_ARCH_CPU = arm.
> > > This includes armhf, which by definition supports hardware floating point.
> 
> > Yes, and this was a conscious and considered decision, not an oversight
> > or accident.
> 
> > > In Ubuntu, a patch has been applied to speex to enable floating point
> > > support on armhf, in response to <https://bugs.launchpad.net/bugs/1125295>.
> > > 
> > > The patch is attached for your consideration.
> 
> > I have had this request arrive in various forms a few times now, and so
> > far I've always knocked it back after a discussion that typically goes
> > something like this:
> 
> >   > > Have you benchmarked this?  Can you share your tests and results
> >   > > that show what systems, if any, perform better and by how much?
> 
> >   > No, but ...
> 
> > At which point I usually have to try hard to think of something polite
> > and constructive to say :)
> 
> > So if you have some rigorous benchmarks, preferably over a broad range
> > of the hardware supported by that arch (since the quality of the FPUs
> > in them do vary quite significantly), and over a wide range of source
> > material using both the codec and the DSP extras, then I'm definitely
> > still quite interested in seeing those.
> 
> > But without that, I can only go by the numbers we ran when we made this
> > decision, which didn't leave a lot of doubt about what the best thing
> > to do was going to be.
> 
> Where can I find the numbers, and benchmark source, that you ran at the time
> you made this decision?  This package change was made in 2008 on the basis
> of testing on the *armel* architecture, which *is* an integer-only
> architecture by definition.  Any benchmarks you did at the time are not
> relevant to or valid for the armhf architecture.  None of the chips that
> armhf runs on *existed* when this decision was made.

You're drawing a rather long bow to connect "we optimised for several of
the existing architectures in 2008" with the false proposition that "no
other architecture has been evaluated for its best configuration since".

Arch-specific changes were made since then, *including* for armhf.  It
already has its own special case in /rules, which as you note, could not
have possibly been added in 2008 ...

> > New information might be compelling in a way that "Ubuntu did this"
> > or "but hardware is magic" are not, lots of things have changed since
> > we did check this, but I'd want to see at the least how this affects
> > both the 'top end' and 'bottom end' of machines supported by armhf,
> > to get a sense of the damage/benefit spectrum we might be looking at.
> 
> The behavior you're encoding in debian/rules today is written to accomodate
> the bottom end of *armel*, which includes chips with no FPU whatsoever.  The
> bottom end of armhf is above the *top* end of armel that existed at the time
> this decision was made.  You are demanding extraordinary proof in response
> to a request to treat armhf as a normal modern architecture, instead of
> lumping it in with armel (which is not).

I'm pretty sure the laws of physics didn't suddenly change with the
introduction of "normal modern architectures" (whatever that means).

There's absolutely nothing "extraordinary", or even "vaguely surprising"
about the results that led to this decision being a clear best choice
for the systems *with FPUs* that it was expected to run on when the armhf
port was introduced.

If you're shocked by that, then now you've got two reasons to go and
run some benchmarks, so that in future your guesses about what might
be optimal can be grounded a little more firmly in educated reality :)


> The burden of proof is on you to show that there is a reason to disregard
> the hardware FP support that's common to all armhf systems.

It's not my job to educate everyone on the internet who believes in voodoo
about the magic of science.

> If you choose not to, that's on your head.

I think I can live with that :)

If someone presents actual data that shows reality on the ground has
changed, in ways that are significant here, then I'll be very interested
in that.  But I'm not going to drop everything to confirm that it hasn't
every time someone armed with a bag of broken assumptions asserts that
what they imagined without testing must clearly trump an empiric reality
that's well known by anyone who has actually examined it first hand.

Sorry.

> I'm not going to spend my time chasing arbitrary benchmarking requirements
> to disprove an assertion which you don't have any benchmarks to support in
> the first place.

If you want to turn down the chance to learn something that might surprise
you, and instead blindly maintain a fork that almost certainly penalises
your users, then that's your prerogative.  And of course on your head :)

If you want to bring some facts to the table though, then I'm always most
interested in those.  Simple evidence is always more convincing than
confrontational ignorance.  And that's all I'm asking for here.

Imagining (wrongly) what I must have done or thought, and then arguing
against that straw man is a pretty poor substitute for presenting some
even rudimentary performance numbers to support your claims.

I'm not going to call a sketchy test conclusive, but it might help you
to put your first instincts into perspective a bit better, and hint at
whether further more detailed investigation might be valuable or not.


Anyhow, your call.  If you want to research this, I'll keep it open to
collate the results.  If you don't, that's fine with me too.

  Cheers,
  Ron