[FFmpeg-devel] [RFC] AES init

[Trent Piepho]

On Sun, 13 May 2007, Michael Niedermayer wrote:
> On Sun, May 13, 2007 at 11:28:03AM -0700, Trent Piepho wrote:
> > On Sun, 13 May 2007, Luca Barbato wrote:
> > > Rich Felker wrote:
> > > >
> > > > Personally I'm against runtime initialization. All the data is
> > > > constant! Include these tables as static arrays in the text/rodata
> > > > segment and they'll use less memory and the race condition goes away
> > > > permanently without hackish solutions like this.
> > >
> > > The only problem is that it would consume memory needlessly, still it is
> > > less complicated than the other solution proposed.
> >
> > Decent OSes have demand paged executables, so the table would only be loaded
> > off disk when it is used.  It depends on how big the table is and what ends up
> > on the same pages (usually 4k) as to how much gets loaded when it's not
> > needed.
> >
> > One must also keep in mind that the code to initialize the table and code
> > that calls the initializing code also takes up disk space and demand paged
> > memory the same way the table does.  In terms of size or speed, there's no
> > point in replacing a 256 byte table with 500 bytes of initialization code.
>
> yes
>
> the tables need 8704 byte
> the init code needs 634 byte
> with -O2 -Os the init code needs 419 byte
>
> with -DCONFIG_SMALL -O2 -Os
> tables: 2560 byte
> init code: 368 byte

There is also the code to check if the tables need to be initialized and to
call the init function, but unless that ends up happening at many different
places it's unlikely to add up to more than a couple bytes.

Storing tables in .rodata has a couple other advantages:

The paging system can drop rodata pages from memory without needing to write
them to swap.  Data generated at run time must be written to swap to be paged
out.  Probably not very important for small tables.

rodata pages can be shared across multiple processes running the same binary,
or, in the case of shared libraries, multiple different binaries that use the
same shared library.  It also trivial to shared them across threads, but that
can be done with generated tables too, but it's not as simple.

The tables can be cached by the OS as part of the page cache.  If the
executable is run again or the shared library re-used, the exiting copy of the
tables in the page cache can be used without needing to reload the page from
disk or re-generate the tables in memory.  Tables generated at run time must
be re-generated each time (though the code that generates them could be
cached).

On the other hand, generating tables could be faster in some cases than
reading them off disk (when the data isn't already cached).  It would
depend on the number of extra disk reads and how fast generating the
table is.