On Sat, Oct 31, 2015 at 2:30 PM, Nicolas George wrote:
> Le decadi 10 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> For the benefit of the thread, here is a benchmark for the find_motion
>> function to address this point:
>> new:
>> 1815531917 decicycles in find_motion,1024 runs, 0
Le decadi 10 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> For the benefit of the thread, here is a benchmark for the find_motion
> function to address this point:
> new:
> 1815531917 decicycles in find_motion,1024 runs, 0 skips
>
> old:
> 1900282483 decicycles in find_motion,10
On Sat, Oct 31, 2015 at 1:27 PM, Ganesh Ajjanagadde wrote:
> On Sat, Oct 31, 2015 at 12:43 PM, Nicolas George wrote:
>> Le decadi 10 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>>> Entirely possible. I just did this as a low hanging fruit. I highly
>>> suspect that the algorithm can be impr
On Sat, Oct 31, 2015 at 12:43 PM, Nicolas George wrote:
> Le decadi 10 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> Entirely possible. I just did this as a low hanging fruit. I highly
>> suspect that the algorithm can be improved (see Michael's comment).
>> The start/stop was just around t
Le decadi 10 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> Entirely possible. I just did this as a low hanging fruit. I highly
> suspect that the algorithm can be improved (see Michael's comment).
> The start/stop was just around the qsort statement. Since you asked
So the speedup observed m
On Sat, Oct 31, 2015 at 9:59 AM, Clément Bœsch wrote:
> On Sat, Oct 31, 2015 at 08:47:37AM -0400, Ganesh Ajjanagadde wrote:
>> On Sat, Oct 31, 2015 at 6:19 AM, Nicolas George wrote:
>> > Le nonidi 9 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> >> Sample benchmark (x86-64, Haswell, GNU/Lin
On Sat, Oct 31, 2015 at 08:47:37AM -0400, Ganesh Ajjanagadde wrote:
> On Sat, Oct 31, 2015 at 6:19 AM, Nicolas George wrote:
> > Le nonidi 9 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> >> Sample benchmark (x86-64, Haswell, GNU/Linux):
> >> File: original from https://trac.ffmpeg.org/ticket
On Sat, Oct 31, 2015 at 6:19 AM, Nicolas George wrote:
> Le nonidi 9 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> Sample benchmark (x86-64, Haswell, GNU/Linux):
>> File: original from https://trac.ffmpeg.org/ticket/1430
>> command: ffmpeg -stream_loop 8 -i file.webm -vf deshake=rx=64:ry=64
On Sat, Oct 31, 2015 at 11:19:04AM +0100, Nicolas George wrote:
> Le nonidi 9 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> > Sample benchmark (x86-64, Haswell, GNU/Linux):
> > File: original from https://trac.ffmpeg.org/ticket/1430
> > command: ffmpeg -stream_loop 8 -i file.webm -vf deshake=
Le nonidi 9 brumaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> Sample benchmark (x86-64, Haswell, GNU/Linux):
> File: original from https://trac.ffmpeg.org/ticket/1430
> command: ffmpeg -stream_loop 8 -i file.webm -vf deshake=rx=64:ry=64 -f null -
>
> Timer truncated at 1024 runs.
> new:
> 39676
On Fri, Oct 30, 2015 at 07:10:52PM -0400, Ganesh Ajjanagadde wrote:
> qsort is called indirectly in filter_frame, suggesting its performance
> criticality. AV_QSORT is substantially faster due to the inlining of the
> comparison callback. Thus, the increase in performance should be worth
> the incr
qsort is called indirectly in filter_frame, suggesting its performance
criticality. AV_QSORT is substantially faster due to the inlining of the
comparison callback. Thus, the increase in performance should be worth
the increase in binary size.
Sample benchmark (x86-64, Haswell, GNU/Linux):
File: o
12 matches
Mail list logo
