On Mon, Jan 4, 2016 at 2:45 AM, Michael Niedermayer
wrote:
> On Sun, Jan 03, 2016 at 09:11:28PM -0800, Ganesh Ajjanagadde wrote:
>> On Sun, Jan 3, 2016 at 7:32 PM, Michael Niedermayer
>> wrote:
>> > On Mon, Jan 04, 2016 at 04:04:02AM +0100, Michael Niedermayer wrote:
>> >> On Wed, Dec 30, 2015 at
On Mon, Jan 4, 2016 at 1:29 AM, Clément Bœsch wrote:
> On Sun, Jan 03, 2016 at 09:49:33PM -0800, Ganesh Ajjanagadde wrote:
>> On Sun, Jan 3, 2016 at 1:30 PM, Carl Eugen Hoyos wrote:
>> > Carl Eugen Hoyos ag.or.at> writes:
>> >
>> >> Ganesh Ajjanagadde mit.edu> writes:
>> >>
>> >> > No one has t
On Mon, Jan 4, 2016 at 6:13 AM, Andreas Cadhalpun
wrote:
> Hi Ganesh,
>
> On 04.01.2016 06:49, Ganesh Ajjanagadde wrote:
>> Generally, my strengths are in algorithmic/mathematical/numerical
>> improvements. I have a strong interest in security (both its
>> "practical" and "theoretical" variants),
Hi Ganesh,
On 04.01.2016 06:49, Ganesh Ajjanagadde wrote:
> Generally, my strengths are in algorithmic/mathematical/numerical
> improvements. I have a strong interest in security (both its
> "practical" and "theoretical" variants), but with nowhere near the
> same level of knowledge.
>
> Clarific
On Sun, Jan 03, 2016 at 09:11:28PM -0800, Ganesh Ajjanagadde wrote:
> On Sun, Jan 3, 2016 at 7:32 PM, Michael Niedermayer
> wrote:
> > On Mon, Jan 04, 2016 at 04:04:02AM +0100, Michael Niedermayer wrote:
> >> On Wed, Dec 30, 2015 at 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
> >> > This gets rid
On Sun, Jan 03, 2016 at 09:49:33PM -0800, Ganesh Ajjanagadde wrote:
> On Sun, Jan 3, 2016 at 1:30 PM, Carl Eugen Hoyos wrote:
> > Carl Eugen Hoyos ag.or.at> writes:
> >
> >> Ganesh Ajjanagadde mit.edu> writes:
> >>
> >> > No one has told me what is interesting
> >>
> >> Did you look at tickets #
On Sun, Jan 3, 2016 at 1:30 PM, Carl Eugen Hoyos wrote:
> Carl Eugen Hoyos ag.or.at> writes:
>
>> Ganesh Ajjanagadde mit.edu> writes:
>>
>> > No one has told me what is interesting
>>
>> Did you look at tickets #4441 or #4085?
>
> Or ticket #4829 or a j2k issue?
Thanks a lot for taking the time
On Sun, Jan 3, 2016 at 7:32 PM, Michael Niedermayer
wrote:
> On Mon, Jan 04, 2016 at 04:04:02AM +0100, Michael Niedermayer wrote:
>> On Wed, Dec 30, 2015 at 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
>> > This gets rid of some branches to speed up table generation slightly
>> > (impact higher on
On Mon, Jan 04, 2016 at 04:04:02AM +0100, Michael Niedermayer wrote:
> On Wed, Dec 30, 2015 at 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
> > This gets rid of some branches to speed up table generation slightly
> > (impact higher on mulaw than alaw). Tables are identical to before,
> > tested with
On Wed, Dec 30, 2015 at 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
> This gets rid of some branches to speed up table generation slightly
> (impact higher on mulaw than alaw). Tables are identical to before,
> tested with FATE.
>
> Sample benchmark (Haswell, GNU/Linux+gcc):
> old:
> 313494 decic
Carl Eugen Hoyos ag.or.at> writes:
> Ganesh Ajjanagadde mit.edu> writes:
>
> > No one has told me what is interesting
>
> Did you look at tickets #4441 or #4085?
Or ticket #4829 or a j2k issue?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel
Ganesh Ajjanagadde mit.edu> writes:
> No one has told me what is interesting
Did you look at tickets #4441 or #4085?
(Careful about the license for the second one.)
But you can only decide for yourself what you
find interesting...
Carl Eugen
___
ffm
On Sun, Jan 3, 2016 at 9:35 AM, Kieran Kunhya wrote:
>> It is still "speed critical" enough for people to retain
>> CONFIG_HARDCODED_TABLES. My goal here is simple: I want to get cycle
>> count down enough so that hardcoded tables can be removed here.
>
> How are you going to guarantee this across
On Sun, Jan 3, 2016 at 9:35 AM, Kieran Kunhya wrote:
>> It is still "speed critical" enough for people to retain
>> CONFIG_HARDCODED_TABLES. My goal here is simple: I want to get cycle
>> count down enough so that hardcoded tables can be removed here.
>
> How are you going to guarantee this across
On Sun, Jan 3, 2016 at 9:43 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Jan 3, 2016 at 11:21 AM, Ganesh Ajjanagadde
> wrote:
>
>> It is still "speed critical" enough for people to retain
>> CONFIG_HARDCODED_TABLES. My goal here is simple: I want to get cycle
>> count down enough so that hardcod
Hi,
On Sun, Jan 3, 2016 at 11:21 AM, Ganesh Ajjanagadde
wrote:
> It is still "speed critical" enough for people to retain
> CONFIG_HARDCODED_TABLES. My goal here is simple: I want to get cycle
> count down enough so that hardcoded tables can be removed here.
Can you explain why? Does CONFIG_HA
> It is still "speed critical" enough for people to retain
> CONFIG_HARDCODED_TABLES. My goal here is simple: I want to get cycle
> count down enough so that hardcoded tables can be removed here.
How are you going to guarantee this across all arches?
Whilst by all means feel free to work on what y
On Sun, Jan 3, 2016 at 6:13 AM, Michael Niedermayer
wrote:
> On Wed, Dec 30, 2015 at 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
>> This gets rid of some branches to speed up table generation slightly
>> (impact higher on mulaw than alaw). Tables are identical to before,
>> tested with FATE.
>>
>>
On Wed, Dec 30, 2015 at 08:34:55PM -0800, Ganesh Ajjanagadde wrote:
> This gets rid of some branches to speed up table generation slightly
> (impact higher on mulaw than alaw). Tables are identical to before,
> tested with FATE.
>
> Sample benchmark (Haswell, GNU/Linux+gcc):
> old:
> 313494 decic
On Wed, Dec 30, 2015 at 8:34 PM, Ganesh Ajjanagadde
wrote:
> This gets rid of some branches to speed up table generation slightly
> (impact higher on mulaw than alaw). Tables are identical to before,
> tested with FATE.
>
> Sample benchmark (Haswell, GNU/Linux+gcc):
> old:
> 313494 decicycles in
This gets rid of some branches to speed up table generation slightly
(impact higher on mulaw than alaw). Tables are identical to before,
tested with FATE.
Sample benchmark (Haswell, GNU/Linux+gcc):
old:
313494 decicycles in build_alaw_table,4094 runs, 2 skips
315959 decicycles in build_
21 matches
Mail list logo
