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

Måns Rullgård mru
Tue Jul 4 21:32:21 CEST 2006

Rich Felker <dalias at aerifal.cx> writes:

> 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

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

> 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.  Would your 2 pages
provide equivalent functionality?

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

Without more details it's hard to comment.

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

> Now scale these numbers to Mozilla

C++, doesn't count.

> or X.org and ask why compiling such programs is so painful.

Never had any problems compiling X.

M?ns Rullg?rd
mru at inprovide.com

More information about the ffmpeg-devel mailing list