Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.internals
Subject: Re: Fundamental defect of the concept of shared libraries
Message-ID: <8029@auspex.auspex.com>
Date: 25 May 91 17:38:35 GMT
Article-I.D.: auspex.8029
References: <1991May20.163317.19968@decuac.dec.com> <1991May20.175555.13943@batcomputer.tn.cornell.edu> <224@titccy.cc.titech.ac.jp>
Organization: Auspex Systems, Santa Clara
Lines: 25

>>In the proceedings of the Summer 1990 Usenix Conference (Anaheim) there
>>are two papers describing different implementations of shared libraries.
>>Both papers present results.  Both papers conclude that for programs not
>>dominated by startup costs,
>
>Marc Sabatella's paper gives data, 10% for ineffecient coding of library
>and maximum of 10% of start up overhead with reasonably large programs.

Marc Sabatella's paper says that the overhead of PIC is about 10%, and
also notes that since only the libraries are PIC, "this has a negligible
effect on the performance of most programs".  I'm curious whether that
statement is intended to apply to window-system programs or not; I
wouldn't be surprised if they didn't spend more time in library code.

>As I already said, PIC (Position Independent Code) imposes several
>restrictions to hardware, which many architectures can't obey.

Which architectures?  SPARC obviously isn't one of them, and HP-PA
isn't, either, as the HP folks also did their shared libraries on Series
800 machines.  So far, MIPS R-series doesn't seem to be one, either; its
branch instructions are position-independent, and it can do an
unconditional "branch to subroutine", so it can get the PC of the
beginning of the routine into a register with position-independent code.
The Motorola 88K isn't one, either; check out the System V Release 4 ABI
for the 88K.