On 22 March 2016 at 19:28, Ganesh Ajjanagadde <gajja...@gmail.com> wrote:
> On Tue, Mar 22, 2016 at 12:09 PM, Rostislav Pehlivanov
> <atomnu...@gmail.com> wrote:
> > On 22 March 2016 at 17:33, Ganesh Ajjanagadde <gajja...@gmail.com>
> wrote:
> >
> >> On Sat, Mar 19, 2016 at 2:36 AM, Hendrik Leppkes <h.lepp...@gmail.com>
> >> wrote:
> >> > On Sat, Mar 19, 2016 at 3:27 AM, Ganesh Ajjanagadde <
> gajja...@gmail.com>
> >> wrote:
> >> >> Yields speedup in quantize_bands, and non-negligible speedup in aac
> >> encoding overall.
> >> >>
> >> >> Sample benchmark (Haswell, -march=native + GCC):
> >> >> new:
> >> >> [...]
> >> >> 553 decicycles in quantize_bands, 2097136 runs, 16 skips9x
> >> >> 554 decicycles in quantize_bands, 4194266 runs, 38 skips8x
> >> >> 559 decicycles in quantize_bands, 8388534 runs, 74 skips7x
> >> >>
> >> >> old:
> >> >> [...]
> >> >> 711 decicycles in quantize_bands, 2097140 runs, 12 skips7x
> >> >> 713 decicycles in quantize_bands, 4194277 runs, 27 skips4x
> >> >> 715 decicycles in quantize_bands, 8388538 runs, 70 skips3x
> >> >>
> >> >> old:
> >> >> ffmpeg -f lavfi -i anoisesrc -t 300 -y sin_new.aac 4.58s user 0.01s
> >> system 99% cpu 4.590 total
> >> >>
> >> >> new:
> >> >> ffmpeg -f lavfi -i anoisesrc -t 300 -y sin_new.aac 4.54s user 0.02s
> >> system 99% cpu 4.566 total
> >> >>
> >> >> Signed-off-by: Ganesh Ajjanagadde <gajja...@gmail.com>
> >> >> ---
> >> >> libavcodec/aacenc_utils.h | 33 +++++++++++++++++++++++++--------
> >> >> 1 file changed, 25 insertions(+), 8 deletions(-)
> >> >>
> >> >> diff --git a/libavcodec/aacenc_utils.h b/libavcodec/aacenc_utils.h
> >> >> index 38636e5..0203b6e 100644
> >> >> --- a/libavcodec/aacenc_utils.h
> >> >> +++ b/libavcodec/aacenc_utils.h
> >> >> @@ -62,18 +62,35 @@ static inline int quant(float coef, const float
> Q,
> >> const float rounding)
> >> >> return sqrtf(a * sqrtf(a)) + rounding;
> >> >> }
> >> >>
> >> >> +static inline float minf(float x, float y) {
> >> >> + return x < y ? x : y;
> >> >> +}
> >> >> +
> >> >
> >> > Thats exactly what the FFMIN macro expands to, whats the reason for
> >> > introducing this function?
> >>
> >> There was some compilation difference, in particular this was faster.
> >> No idea why, maybe some repeated evaluation of qc + rounding?
> >>
> >>
> > "No idea why" is not even remotely a valid excuse to have your own
> function
> > which does exactly what FFMIN does.
>
> Please read completely before posting, I gave a reason right above
> that. More verbose description given below.
>
> 1. FFMIN is a macro, this is a function. FFMIN etc have problems with
> recomputation, they have extra mental overhead of things like
> FFMIN(f(), g()) for repeated calls.
> 2. I actually ran into a slowdown while playing with this function,
> reaffirming point 1. That slowdown no longer exists when I
> restructured the code into its current form.
>
> Anyway, why are we even discussing this? I am not going to play the
> game of submitting to each and every whim, taking the effort of
> posting new patches, only to have a final statement like "0.1% is not
> worth it". It wastes time for both of us.
>
> In other words, let me know if you actually want to move forward with
> both of these. Else, I will drop them.
>
>
Drop them. I've started work on some SIMD which should boost performance by
quite a lot.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
