[FFmpeg-devel] [RFC] AES init
Wed May 23 01:21:08 CEST 2007
On 5/13/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Sun, May 13, 2007 at 08:02:37PM +0200, Reimar D?ffinger wrote:
> > Hello,
> > On Sun, May 13, 2007 at 07:38:15PM +0200, 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.
> > ?? It will consume extra disk space, but not any more memory. Actually
> > it will consume _less_ in some ways, since it can be swapped out to the
> > original binary instead of using swap space if you really need all that
> > memory.
> it would need less virtual memory and less swap space but not less
> physical memory
> now IMHO virtual memory and swap space is not that much of a limited resource
> that this would matter much, i mean it starts mattering if we would be
> speaking of 100mb or so but here the object file size matters very much too
> and the object may be fragmented on the disk while the swap partition is not
> so loading the stuff from the object file will be slower
> now if there are multiple instances of the code in memeory the rodata-table
> variant has the big advantage of being easily shareable though the init
> based code is theoretically also shareable its just tricky for the kernel
> so IMHO
> if the init code is similarely large or larger than the table then putting
> the table in rodata is the obvious winner
> if OTOH the init code is significantly smaller than the table then things
> start drifting into the philosohical "whats more important" area
> i don think putting 500mb into rodata and thus into the object is the
> correct thing to do
> i wish there where a inited-rodata which would be shareable between
> processes and the kernel would just throw the data away if it needed
> the memory and call the init code again if it needed the table again ...
Not to mention that that would solve a LOT of FFMPEG's multithreading problems.
More information about the ffmpeg-devel