lavc/aacenc_utils: replace powf(x,y) by expf(logf(x), y)

This is ~2x faster for y not an integer on Haswell+GCC, and should
generally be faster due to the fact that anyway powf essentially does
this under the hood. Made an inline function in lavu/internal.h for this
purpose.

Note that there are some accuracy differences, that should generally be
negligible. In particular, FATE still passes on this platform.

Results in ~ 7% speedup in aac encoding with -march=native, Haswell+GCC.
before:
ffmpeg -i sin.flac -acodec aac -y sin_new.aac  6.05s user 0.06s system 104% cpu 5.821 total

after:
ffmpeg -i sin.flac -acodec aac -y sin_new.aac  5.67s user 0.03s system 105% cpu 5.416 total

This is also faster than an alternative approach that pulls in powf, gets rid of
the crufty NaN checks and other special cases, exploits knowledge about the intervals, etc.
This of course does not exclude smarter approaches; just suggests that
there would need to be significant work on this front of lower utility than
searches for hotspots elsewhere.

Reviewed-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanag@gmail.com>

1 files changed, 16 insertions, 0 deletions

diff --git a/libavutil/internal.h b/libavutil/internal.h
index da76ca26d3..340e18bc5d 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -315,6 +315,22 @@ static av_always_inline float ff_exp10f(float x)
 }
 
 /**
+ * Compute x^y for floating point x, y. Note: this function is faster than the
+ * libm variant due to mainly 2 reasons:
+ * 1. It does not handle any edge cases. In particular, this is only guaranteed
+ * to work correctly for x > 0.
+ * 2. It is not as accurate as a standard nearly "correctly rounded" libm variant.
+ * @param x base
+ * @param y exponent
+ * @return x^y
+ */
+static av_always_inline float ff_fast_powf(float x, float y)
+{
+    return expf(logf(x) * y);
+}
+
+
+/**
  * A wrapper for open() setting O_CLOEXEC.
  */
 av_warn_unused_result