[FFmpeg-devel] [PATCH][WIP] lavc/cbrt_tablegen: speed up tablegen

[Ronald S. Bultje]

Hi,

On Fri, Jan 1, 2016 at 10:46 AM, Ganesh Ajjanagadde <gajjanagadde at gmail.com>
wrote:

> On Fri, Jan 1, 2016 at 7:43 AM, Ronald S. Bultje <rsbultje at gmail.com>
> wrote:
> > Hi,
> >
> > On Fri, Jan 1, 2016 at 10:40 AM, Ganesh Ajjanagadde <
> gajjanagadde at gmail.com>
> > wrote:
> >>
> >> On Fri, Jan 1, 2016 at 6:54 AM, Ronald S. Bultje <rsbultje at gmail.com>
> >> wrote:
> >> > Hi,
> >> >
> >> > On Thu, Dec 31, 2015 at 9:55 PM, Ganesh Ajjanagadde
> >> > <gajjanagadde at gmail.com>
> >> > wrote:
> >> >>
> >> >> This exploits an approach based on the sieve of Eratosthenes, a
> popular
> >> >> method for generating prime numbers.
> >> >>
> >> >> Tables are identical to previous ones.
> >> >>
> >> >> Tested with FATE. Does not work yet with --enable-hardcoded-tables
> due
> >> >> to the union and lack of proper WRITE_ARRAY for it. Want to get
> >> >> feedback
> >> >> on this; if we always dynamically init it this won't need addressing.
> >> >
> >> >
> >> > I think you're getting ahead of yourself here. Assume for now that the
> >> > hardcoded-tables feature will continue to exist for a while.
> >>
> >> I was referring to just this one, not to the question in general.
> >
> >
> > I was also referring to this case specifically. Assume, for now, that
> > hardcoded tables for this specific case, will continue to exist.
>
> Then defend it technically please. For instance, you have not
> addressed the fundamental amortization of table init cost.


No. It is the status quo, and remains that until it changes. That's why
it's called the status quo. I've encouraged you several times to have this
debate in the open, but you keep jumping away when that comes up.

Ronald