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...@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.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
