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

[Steve Langasek]

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.

> 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).

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.  If you choose
not to, that's on your head.  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.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20140129/8a1729d5/attachment.sig>