[Ffmpeg-devel] [PATCH] Intel Mac MMX/SSE2 support

[Rich Felker]

On Sat, Jul 01, 2006 at 12:21:20PM +0100, M?ns Rullg?rd wrote:
> Rich Felker <dalias at aerifal.cx> writes:
> 
> > On Fri, Jun 30, 2006 at 10:36:24AM +0100, M?ns Rullg?rd wrote:
> >> 
> >> Michael Niedermayer said:
> >> 
> >> > btw, how hard is it for mac-intel users to download and use non-apple gcc?
> >> > i mean does unmodified gcc work on mac-intel?
> >> 
> >> This is an issue with gas, not gcc.  And no, stock binutils don't work on
> >> macintel.  Why, oh why, couldn't they just use ELF for their binaries?
> >
> > Actually it's very good that they don't, since ELF sucks and the
> 
> Would you care to elaborate a little on why ELF sucks so badly?

Here is a good starting point:
http://plan99.net/autopackage/Linux_Problems#elf

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).

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.

ELF encourages nonportability by virtue of feature-creep. Certain
implementations (i.e. GNU) keep adding features to abuse linking
semantics in order to make their implementation of system libraries
(i.e. glibc) "easier" rather than solving the problems using the
standard C language (which from my experience is equally easy).

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

Now scale these numbers to Mozilla or X.org and ask why compiling such
programs is so painful. Keep in mind the problem is most severe on
well-factored code where each object file just contains a small amount
of code, so numbers may vary widely across projects, but it doesn't
change the fact that ELF is horribly bloated, mis/over-designed, etc.

Rich