[Ffmpeg-devel] [PATCH] Intel Mac MMX/SSE2 support
Wed Jul 5 00:46:04 CEST 2006
On Tue, Jul 04, 2006 at 08:32:21PM +0100, M?ns Rullg?rd wrote:
> >> Would you care to elaborate a little on why ELF sucks so badly?
I hope you won't find my rants OT or annoying. You asked for them.
> > Here is a good starting point:
> > http://plan99.net/autopackage/Linux_Problems#elf
> A few thoughts about that page that spring to my mind:
> - It discusses problems of shipping *precompiled binaries* for users
> to install and run. Since when do you care whatsoever about that?
> - I happen to think the ELF way of dependencies is the right way.
> - The page contains the word "enterprise", which makes it inherently
It's not a matter of the site being trustworthy; you can verify the
issues for yourself. I agree that their goals (binary compat) are
stupid but their conclusions are nonetheless correct.
As for the dependencies, the performance is fundamentally unacceptably
bad. Dynamic linking performance should not go to hell with increased
number of global symbols. If it does, all large apps will load slowly
just like Windows/KDE/GNOME/Mozilla/etc. already do.
> > Other issues:
> > During my analysis while implementing libc and trying to build small
> > binaries, I determined that the practical minimum overhead for ELF
> > dynamic linked binaries is about 8 dirty pages plus at least one dirty
> > page per library. This is compared to the theoretical minimum with PIC
> > which is 2 dirty pages plus one per library, or without PIC and
> > pre-relocated (which is 2 dirty pages total).
> 6 pages per app doesn't seem all that awful.
6 plus 1 per library. Big difference. At least add libc/libm. And
maybe libcurses. And maybe libz. ...
Soon you'll find a very very low upper limit on the number of
processes on a low-memory system just due to this overhead.
> Would your 2 pages
> provide equivalent functionality?
No, it provides different functionality. Which is better depends on
your needs. In my system, performance is much higher (O(1)) and memory
usage is much smaller because no linking is performed at runtime, only
sharing of text pages.
> > ELF does not page-align the segments on disk. Actually it can with
> > padding, but the GNU tools intentionally do not do so with the
> > supplied linking scripts, for whatever reason. This means that even
> > programs or libraries with only a few global variables will often use
> > two whole pages of data (dirty pages) due to data starting at the very
> > end of one page and flowing over to the beginning of another.
> Do not blame the spec for shortcomings in one implementation.
> > ELF object files are INSANELY bloated. This is why it takes 500 megs
> > of disk space to compile a project whose final binary will be 20 megs.
> > This is also why compile performance for large projects is incredibly
> > poor, since all this disk io obliterates the filesystem cache. To cite
> > some numbers:
> > a.out object files:
> > -rw-r--r-- 1 dalias users 212902 Jun 29 12:35 libc.a
> > -rw-r--r-- 1 dalias users 7246 Jun 18 00:40 libegacy.a
> > -rw-r--r-- 1 dalias users 75514 Jun 30 03:16 libm.a
> > ELF object files:
> > -rw-r--r-- 1 dalias users 449222 Jul 4 15:07 libc.a
> > -rw-r--r-- 1 dalias users 19844 Jul 4 15:07 libegacy.a
> > -rw-r--r-- 1 dalias users 123010 Jul 4 15:07 libm.a
> a.out doesn't provide nearly equivalent functionality of ELF.
> Comparing the sizes is pointless.
I can guarantee you that 90% of that size difference is not
functionality but useless bloated file structures. The only actual
"features" are a few bits per symbol of attributes, sizes, arbitrary
sections, ..., none of which except symbol size/type were even used in
the above files.
However what's more important is that comparing the size _does_ have a
point, because a.out has all the features necessary to implement the
linking semantics of the C language. If you're writing C code,
anything beyond it is useless bloat. It's quite reasonable to assume
that the ELF semantics, which emulate traditional unix linking
semantics outside the C standard at runtime, were created for the
purpose of implementing hacks like pthread through symbol
interposition. The semantics are only different from the obvious,
efficient, tree model in the case of programs with undefined behavior!
> > Now scale these numbers to Mozilla
> C++, doesn't count.
Object file size still is an issue.
> > or X.org and ask why compiling such programs is so painful.
> Never had any problems compiling X.
You deny that it's slow and uses huge amounts of disk space?
More information about the ffmpeg-devel