[Ffmpeg-devel] [PATCH] Intel Mac MMX/SSE2 support
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:
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.
mru at inprovide.com
More information about the ffmpeg-devel