[FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[Clément Bœsch]

On Mon, Oct 03, 2016 at 04:17:00PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Mon, Oct 3, 2016 at 4:11 PM, Clément Bœsch <u at pkh.me> wrote:
> 
> > On Mon, Oct 03, 2016 at 09:48:47PM +0200, Nicolas George wrote:
> > > Le duodi 12 vendémiaire, an CCXXV, u-9iep at aetey.se a écrit :
> > > > The author of the referred code acts in his actual area of competence
> > > > (C libraries and standards).
> > > >
> > > > The comments here on the C library code and standard compliance come
> > from
> > > > developers having a different competence area (multimedia programming).
> > > >
> > > > As bright as the people here are, they land in a foreign area, which
> > > > accidentally leads to statements like the above.
> > >
> > > I am sorry, but an appeal to authority will not cut it in front of real
> > > arguments.
> > >
> > > The real argument here is: musl makes several assumptions about the
> > > architecture and compiler (for example: that floats and ints have the
> > same
> > > endianness) that are not mandated by any standard. And although these
> > > assumptions are very reasonable and widely respected, there will
> > eventually
> > > be an architecture or, more probably, a compiler, that will break them.
> > >
> > > FFmpeg does exactly the same.
> > >
> >
> > TBH, having a set of supported architectures in a libc is much more legit
> > than a set of supported libc in a multimedia framework IMO.
> >
> > We can mess as much as we want within our codebase wrt ABI violations, but
> > I don't think it's reasonable to make random assumptions about libc (and
> > others external libraries) implementations. It's way too risky. Even if we
> > are able today to change musl implementation, seeing random floats usage
> > in the many allocators out there doesn't look that surprising.
> >
> > Actually, if I was a valgrind developers, maybe I would do that on
> > purpose...
> >
> > [...]
> > > In this instance, we know the reason for FFmpeg: resetting the FPU state
> > is
> > > expensive, and this is speed-critical code.
> >
> > We have mallocs in inner loops of speed-critical? Really?
> 
> 
> What code is speed critical? In an audio decoder (like a voice decoder)
> where a decode call plays as many as a few tens of audio samples at best, I
> would say that anything is speed critical, because once-per-frame isn't
> that far off from once-per-sample in that case.

And then you insert an audio filter using floats and you're doomed?

> The bigger problem is that we're talking about malloc (actually, free,
> according to cehoyos) here. But this could be any external/libc function.
> We need emms before any libc call. That's ... Not just mallocs.

Well currently the issue is definitely in the alloc/free, so maybe we
should stick to that problem for now?

BTW, just another allocator using floats:
https://github.com/jemalloc/jemalloc/blob/dev/src/prof.c#L850

-- 
Clément B.