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...@pkh.me> wrote: > > > On Mon, Oct 03, 2016 at 09:48:47PM +0200, Nicolas George wrote: > > > Le duodi 12 vendémiaire, an CCXXV, u-9...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel