[FFmpeg-devel] [PATCH] Move cbrt tables to a separate cbrt_data(_fixed).c files.

[Ganesh Ajjanagadde]

On Sun, Mar 13, 2016 at 1:46 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Sun, Mar 13, 2016 at 01:27:52PM -0400, Ganesh Ajjanagadde wrote:
>> On Sun, Mar 13, 2016 at 1:21 PM, Reimar Döffinger
>> <Reimar.Doeffinger at gmx.de> wrote:
>> >> > I don't understand the waste; the double init anyway needs to be done,
>> >> > all tables are derived from it. This dates to an approach I did in
>> >> > commit:  07a11ebcab9b31e9fc784029e5d24e6fbf486ff3.
>> >>
>> >> The waste is in writing to the table that will never be used.
>> >> As long as it is left as 0, it will not use memory, as soon
>> >> as you touch it it uses up memory.
>> >> But see my patch, if people think it's better it can be added.
>> >
>> > And looking at that commit, I actually realize now that the
>> > cbrt_tab_dbl will also permanently waste 64 kB of memory despite
>> > never being used again.
>> > Using malloc/free for it would potentially be better (though
>> > in general I have some doubts about the wisdom of optimizing
>> > for initialization time at the detriment of runtime performance
>> > or memory usage).
>>
>> --enable-hardcoded-tables partially does that; it increases memory
>> usage as tables are burnt into the library at some gains for
>> initialization time.
>
> No, exactly not. It increases disk usage, but it decreases memory
> usage.
> Tables are not loaded just because they are in the binary, not
> when they are in .rodata.
> If you are really lucky, even when the cbrt tables are used but only
> a small part of them, with --enable-hardcoded-tables you'd not
> even necessarily end up with all of them in RAM (admittedly
> you can also see that as a disadvantage: the chances that
> you end up with a page fault in the middle of decoding when
> you don't really want it is there, too).

Correct me if I am wrong, but I don't think an OS/runtime system
actually loads at the granularity of individual tables. It would load
at the granularity of pages, there can be a greater chance of page
faults with larger images, such as due to larger .rodata.

> Gaining initialization time is absolutely not the point of
> that option, it doesn't make sense and I have no idea
> how that myth came to be (it may admittedly be true
> in some cases, but it's not the point or very relevant).
> Just for AAC CBRT tables (which are small in comparison),
> hardcoded tables saves 128 kB of RAM/swap once you no longer
> use the AAC codecs compared to your patch (64 kB for the
> double table + 2*32kB for the final tables + possibly
> a little bit from not needing the initialization code).

Ok, so the tables are pulled into RAM on a as-needed basis. But then
when are they offloaded? Savings (apart from the 64 kB for the double
table) will only kick in at the time of offloading when the page is
freed.

> Of course 128 kB less in swap space vs. 64 kB more in the
> binary/main storage is not really very useful in most cases,
> but I don't think one can argue it is worse.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel