[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: some netCDF FAQ answers describing what shared libraries are...

From: Noah Misch
Subject: Re: some netCDF FAQ answers describing what shared libraries are...
Date: Sat, 29 Jul 2006 16:55:58 -0700
User-agent: Mutt/1.5.6i

On Thu, Jul 27, 2006 at 08:17:59AM -0600, Ed Hartnett wrote:
> Shared libraries are libraries which can be shared by multiple running
> applications at the same time. This improves performance.

It may improve performance.  There are three major issues that determine the
relative performance of shared and static libraries: differences in the
generated code, total memory consumption, and cache misses.

On many systems, one generates position-independent code (PIC) for use in shared
libraries and non-PIC code for static libraries and programs.  Other systems use
PIC code in all cases (x86 Windows, most/all MIPS-based systems).  PIC code uses
a register to hold the address of the global offset table (GOT); non-PIC can
treat that register as general-purpose for better performance.  Furthermore,
program code that calls a function in a shared library must call through the
procedure linkage table (PLT), which is slower than a direct call to a
locally-defined function, such as from a static library.  The extra code to
facilitate position independence also consumes more space.

As you note, shared libraries can reduce system-wide memory consumption.  For
pervasive libraries like libc, libstdc++, and zlib, this adds up quickly.
Sometimes shared libraries use more memory.  Consider a DSO with 1024 symbols
f000 ... f1023, where each symbol fills 1 KiB.  Suppose you have one program
that uses f0, f128, f256, and f384, and another program that uses f512, f640,
f768, and f896.  A system with 4 KiB pages will use 32 KiB of memory to load
those symbols, versus 8 KiB if you had linked them statically.  That is a
pessimistic example, but real shared libraries can waste memory that way.

Now consider the aforementioned DSO from a cache-utilization perspective.  With
a cache line size not greater than 128 KiB, each call to one of those functions
will load a fresh cache line. If those functions lie in a hot path, this could
kill performance.

Moving to shared libraries often reduces performance, but the degree of
performance loss will depend on the target architecture and on specific
characteristics of the library and its users.  The more programs sharing a
library, the more likely memory economy will make up for any performance
penalties.  Shared libraries do offer dramatic maintenance advantages; for a
significant amount of code, that justifies the performance ambiguity.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]