[FFmpeg-devel] [PATCH] configure, avutil/libm: add fmax, fmaxf, fmin, fminf support

[Ronald S. Bultje]

Hi,

On Thu, Oct 15, 2015 at 9:10 AM, Ganesh Ajjanagadde <gajjanag at mit.edu>
wrote:

> On Thu, Oct 15, 2015 at 8:31 AM, Clément Bœsch <u at pkh.me> wrote:
> > On Thu, Oct 15, 2015 at 08:18:02AM -0400, Ganesh Ajjanagadde wrote:
> >> It has been demonstrated that using libc provided floating point
> >> functions is beneficial, in the context of fabs() vs FFABS.
> >>
> >> Unfortunately, MSVC 2012 (and earlier) lack the ISO C99 fmax, fmaxf,
> >> fmin, fminf functions. This patch adds them, thus making their usage in
> >> FFmpeg safe.
> >>
> >
> > Do we have any use of fmax/fmin? The functions don't exist to make
> > FFMAX-like faster, it actually is more complex:
> >
> >        These functions return the maximum of x and y.
> >
> >        If one argument is a NaN, the other argument is returned.
> >
> >        If both arguments are NaN, a NaN is returned.
> >
> > Which means it's likely slower but will do more. Not that I mind, but in
> this
> > case, if we happen to use them, you will want to fix your local
> implementation
> > to match this behaviour.
>
> 2 comments:
> 1. There is a tradeoff: the gain from possible better optimization of
> >=, versus the nan handling.
> 2. NaN handling is not being done currently (by FFMAX and the like) -
> so I don't know and can't comment whether we want it. You are right
> that if we change to a fmax, we should make it consistent everywhere
> on all platforms . Anyone else has comments on this?


If we provide compat functions for maxf() etc., they should behave
identically to the standard-defined maxf(). Note that this may not be more
complex, bool operations on NaN always return false, you can (ab)use that
to keep checks simple. Write (unit) tests if you're not sure.

Whether we switch from FFMAX to maxf() is a separate question that should
be answered by whether maxf() is actually equally fast / faster or not.
That there's corner case behavioural differences is understood and doesn't
have to be part of this discussion IMO.

Ronald