[MPlayer-dev-eng] More -fPIC fun

Zoltan Hidvegi mplayer at hzoli.2y.net
Mon Aug 16 18:21:47 CEST 2004


> On Sat, 2004-08-14 at 19:02, Ivan Kalvachev wrote:
> > Finnaly. Compiling MPlayer with -fPIC
> > IS VERY BAD IDEA. You are loosing about 5% of the performance and
> > that's why mplayer tries to compile everything staticaly.
> 
> Just curious: Is this true for all architectures, or are we talking
> about the lack of x86 registers here?

In theory PIC can slow down other architectures as well, but you
probably would not notice if the number of registers drops from 30 to
29.  There is also some address calculation overhead related to -fPIC,
but unlike x86, most RISC architectures do not support direct absolute
addressing anyways, so that's not a big issue.  But on 32-bit x86
Linux you can actually compile shared libraries without -fPIC, and
they will work, the disadvantage is that they would not be shared
because the code has to be patched to contain the right addresses.  So
do not do that for libc, as it will blow up the memory usage, but it
does not hurt if you do this for a library which do not usually have
multiple instances present in memory at the same time.  And keep in
mind that on most other architectures, including x86-64 I believe, if
you do not use -fPIC to compile your shared objects, they will
coredump.

Zoli




More information about the MPlayer-dev-eng mailing list