Hi, On Thu, Mar 10, 2016 at 2:37 AM, Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> On 10.03.2016, at 03:06, Ganesh Ajjanagadde <gajja...@gmail.com> wrote: > > > On Wed, Mar 9, 2016 at 2:16 AM, Reimar Döffinger > > <reimar.doeffin...@gmx.de> wrote: > >> On 08.03.2016, at 04:48, Ganesh Ajjanagadde <gajja...@gmail.com> wrote: > >> > >>> + nzl += expf(logf(s / ethresh) * nzslope); > >> > >> Shouldn't log2f/exp2f be faster? > >> log2f at least has CPU support on x86 AFAICT. > > > > I had tested this, and no, though it is still faster than powf. > > > > It still seems to rely on libm, note that we don't use -ffast-math and > > a look at > https://github.com/lattera/glibc/tree/master/sysdeps/x86_64/fpu > > as well seems to say no. Problem is, GNU people like to prioritize > > "correctly rounded" behavior over fast, reasonably accurate code, > > sometimes to ludicruous degrees. > > > > Personally, I don't know why we don't use -ffast-math, not many seem > > to care that heavily on strict IEEE semantics. Maybe it leads to too > > much variation across platforms? > > You lose some guarantees. In particular, the compiler will assume NaNs do > not happen and you cannot predict which code path (after a comparison for > example) they take. > But some code for either security or correctness reasons needs them to be > handled a certain way. > I guess in theory you could try to make sure fisnan is used in all those > cases, but then you need to find them, and I think if you take -ffast-math > description literally there is no guarantee that even fisnan continues to > work... I am also not sure none of the code relies on order of operations > to get the precision it needs. > So it is simply too dangerous. > Some more specific options might be possible to use though (but I think > even full -ffast-math gains you almost nothing? Does it even help here?). One could also consider writing some customized assembly (calling the relevant instructions instead of C wrappers) in cases where it is speed-sensitive. It's sort of the inverse of what Ganesh is suggesting, I guess, maybe some more effort involved but it can't be that much. You could even use av_always_inline functions and inline assembly to call the relevant instruction and otherwise keep things in C. That's identical to what -ffast-math does but turns on only when specifically calling the new API function name... Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
