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.
> Also the bracket should be on a newline.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
