[FFmpeg-devel] [PATCH] lavc/aacenc_utils: unroll abs_pow34_v loop

[Ganesh Ajjanagadde]

On Tue, Mar 22, 2016 at 12:07 PM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> On Tue, Mar 22, 2016 at 8:02 PM, Ganesh Ajjanagadde <gajjanag at gmail.com> wrote:
>> On Tue, Mar 22, 2016 at 11:52 AM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>>> On Tue, Mar 22, 2016 at 7:37 PM, Ganesh Ajjanagadde <gajjanag at gmail.com> wrote:
>>>> On Tue, Mar 22, 2016 at 11:30 AM, Rostislav Pehlivanov
>>>> <atomnuker at gmail.com> wrote:
>>>>> On 22 March 2016 at 18:14, Ganesh Ajjanagadde <gajjanag at gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> Per doc/optimization.txt, aac is a widely used codec, so even a 0.1%
>>>>>> improvement in aac is fair game for optimizations, assuming it is a
>>>>>> small code change. Of course, one can debate whether this is small or
>>>>>> not. I view it as simple and clean, others may disagree.
>>>>>
>>>>>
>>>>> Nope, I still doubt that that 0.1% is a definite performance improvement.
>>>>
>>>> Then change doc/optimization.txt.
>>>
>>> This particular doc doesn't give you a blanket argument. Specifically
>>> if the maintainer objects on account of complexity, you should honor
>>> that - the doc even says as much (ie. only "clean and simple" being
>>> justified)
>>
>> It does not. And of course I honor a maintainer's wishes. If he
>> refuses to accept a performance improvement, so be it.
>>
>> I just want it clear that from my view this is still ridiculous given
>> FFmpeg's track record on these sorts of things in the past. I also
>> find it ironic that there are objections to this on the lines of "what
>> about some (unspecified) platform?", when bccc81dfa was accepted with
>> no problems.
>
> A 7% overall improvement is quite a different topic than 0.1%, isn't
> it. For 7% on all common platforms, one might risk another outcome on
> more obscure cases.

It all depends on what one's priorities are as a project ultimately,
i.e how one weights the importance of the platforms.
My opinion has still not changed.

>
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel