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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
