[FFmpeg-devel] [RFC] Disable compile-time tablegen for cbrt if total cycle count < 200000

[Ganesh Ajjanagadde]

On Sun, Jan 3, 2016 at 3:07 PM, Michael Niedermayer
<michael at niedermayer.cc> wrote:
> On Fri, Jan 01, 2016 at 08:07:39AM -0800, Ganesh Ajjanagadde wrote:
>> Hi all,
>>
>> Motivated by a remark by Ronald:
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186200.html,
>> this is a request for comment on disabling compile time tablegen for
>> cbrt if the total cycle count < 200000. Note that cbrt tables are only
>> used in aacdec.
>
> Its very hard to state a hard number as the threshold, this is quite
> subjective
> and different viewpoints would lead to different results
>
> but lets try anyway
> for the hardcoded table case more data needs to be read from disk
> ATM this is about 2mb for all tables
>
> for dynamic tables the used tables need to be generated
> theres a difference in binary size (table size vs code to generate it),
> that translates into a cost value (bytes * cycles_per_byte)
>
> and the dynamic init needs some time to build the table, thats
> conveniently already in cycles

Indeed; this was why it was easy to quantify the costs of dynamic init above.

>
> (above ignores alot, like HDDs, SDDs disk cache have different speed
>  hardcoded tables can be shared between processes but then rarely would
>  a process use all tables while the OS might end up loading all anyway
>  also we assume a load from cache while a OS might actually map tables
>  from the disk cache directly)
>
> now if the dynamic init is faster than loading the table from
> the disk cache then dynamic init is likely the better choice
>
> using cat into /dev/null i get about 2bytes per cycle
>
> also about START/STOP_TIMER, the decicyles are tens of cycles so
> one tenths of the displayed value is the amount of cpu cycles

Correct me if I am wrong, but I thought I did this above by dividing
the counter by 10.

>
> iam sure if one looks at this from a different angle a quite different
> threshold mathod and value could result

Yes, but here you ignore the table being used by what fraction of
files. --enable-hardcoded-tables as a whole is a ~15-20% size
increase. It is hard to impossible to separate the costs of what
happens here, i.e what files use what tables, when and what things are
loaded, etc. One may be unlucky to hit a page fault, or it may already
be present, who knows. It is thus highly variable.

Seems like you partially address this below. Unfortunately, the above
difficulties are coupled with the lack of ability to quantify the
"fraction of files that use a particular table". This obviously varies
by client use. For example, I have never used dsd myself, but I have
encountered aac frequently.

You have been very consistent and methodical about your responses and
stuck to technical matters, and I highly appreciate this. Thus, if you
wish to continue to keep the hard coded tables ifdefry here (and/or
elsewhere), please say so and I can stop this thread right now to
focus effort elsewhere. I will then continue to improve dynamic init,
but not bother about getting rid of the ifdefry and configure magic.
You may not be project leader, but in this matter, I would really like
a final judgement call from you: it will help give me some clarity.

>
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Opposition brings concord. Out of discord comes the fairest harmony.
> -- Heraclitus
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>