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

Ganesh Ajjanagadde gajjanag at gmail.com
Fri Mar 25 18:40:39 CET 2016


On Tue, Mar 22, 2016 at 4:42 PM, Michael Niedermayer
<michael at niedermayer.cc> wrote:
> On Tue, Mar 22, 2016 at 11:37:16AM -0700, Ganesh Ajjanagadde 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.
>>
>> > Sure it might be on your machine but who knows, maybe for someone else
>> > it'll be a 0.1% decrease in performance or hell, a 1% decrease.
>>
>> Don't speculate, show evidence. This is something that can be said
>> about essentially all patches that affect performance. For example,
>> who knows, a compiler may actually omit worse code on a certain
>> architecture for something that should be an improvement. This just
>> highlights the ridiculousness of this line of reasoning.
>
> if no consense can be found on this ...
> maybe theres an easy way out of this problem ?
> git makes it easy for 2 people to keep some differences
>
> If one doubts changes improve speed and another belives they do
> the 2 can just keep their git trees different.
> And once there are 50 disputed 0.1% improvments one git tree will
> either be 5% faster or not.
> would anyone object to applying 50 small changes which together make
> the code 5% faster ?

That is a very good idea. In fact, it is kind of what is happening
right now; I keep some stuff like this, fclose return checks, etc in
my tree.
The only problem, which can get annoying, is then dumping those 50
changes and getting remarks like they are too many of them, they are
all useless (which may be true individually) etc forcing lots of
refactoring.

>
> of course if people agree on changes in the first place that would
> be even better
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many things microsoft did are stupid, but not doing something just because
> microsoft did it is even more stupid. If everything ms did were stupid they
> would be bankrupt already.
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


More information about the ffmpeg-devel mailing list