Shared vs static link performance hit --and Windows?

[David M. Cooke]

At some point, llothar at web.de (Lothar Scholz) wrote:

> Christos "TZOTZIOY" Georgiou <tzot at sil-tec.gr> wrote in message news:<k7clgvoqjur1f10mosue3os74vv7nd34hi at 4ax.com>...
>> Last night I was compiling the latest python snapshot at my home Linux
>> system (a K6-III @420 --the extra 20 Hz is overclocking :); then I tried
>> building a shared version of the interpreter.  I did some speed
>> comparisons, and pystone reported ~6090 pystones for the shared and
>> ~7680 pystones for the (default) static build.
>> 
>
> Yes, today i recommend to not use the -fPIC option for certain
> libraries when compiling a .so library. If you use it you get one more
> indirection and this can be very bad on systems with long CPU
> pipelines (PIV systems). If you don't use -fPIC then the shared
> library will be patched and is only shared on disk but not in memory.

On PowerPC Linux (or any PPC Unix using ELF), AFAIK, compiling shared
libraries *without* -fPIC will run you into trouble. This is espically
true if you then link to a library that was compiled with -fPIC.
You'll get errors like 'R_PPC_REL24 relocation ...'. I certainly see
problems with bad code that doesn't use -fPIC that runs on x86, but
not on PPC.

x86 has a different way of doing things from PPC that doesn't bite you
on the ass when you compile without -fPIC. You especially run into
trouble when you mix non-fPIC code with -fPIC code.

[while we're on the subject, I'll point out that -fpic and -fPIC are
not equivalent. -fpic can run out of space in the global offset table,
while -fPIC avoids that. x86 doesn't have that limit, so I see people
using -fpic where they should be using -fPIC.]

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm(at)physics(dot)mcmaster(dot)ca