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

[Clément Bœsch]

On Thu, Oct 15, 2015 at 09:10:00AM -0400, Ganesh Ajjanagadde 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.

FFMIN() and FFMAX() are translated to a single instruction on x86 with
floats: minsd/maxsd. I doubt you can do better.

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

If you name the function the same as the system, yes you want to match the
behaviour exactly. Because otherwise, as soon as someone assumes a certain
standard behaviour, there will be nasty surprises on random systems.

[...]

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151015/ca5e9b6b/attachment.sig>