Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!cs.titech!titccy.cc.titech!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.unix.internals
Subject: Re: Fundamental defect of the concept of shared libraries
Message-ID: <224@titccy.cc.titech.ac.jp>
Date: 22 May 91 04:42:00 GMT
References: <213@titccy.cc.titech.ac.jp> <1991May20.090857@wsl.dec.com> <1991May20.163317.19968@decuac.dec.com> <1991May20.175555.13943@batcomputer.tn.cornell.edu>
Sender: news@titccy.cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 40

In article <1991May20.175555.13943@batcomputer.tn.cornell.edu>
	shore@theory.TC.Cornell.EDU (Melinda Shore) writes:

>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.

Moreover, the measurement was done with 68030, which support various
address modes without much performance degradation (because it is already
slow).

>Donn Seeley's paper is
>particularly relevant,

His paper also make measurement with 68030, utilizing its address modes.

I don't say there result is useless. But they are not applicable to
the todays fastest machines.

>in that he's arguing that it is possible to
>have a shared library implementation that is both simple and fast.

See page 30, line 37-38,

	"The PIC implementation is the heart of this prototype"

Similar thing is written in "Conclusion" section, also.

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

>You just have to know what you're doing.

You had better read papers you referred.

						Masataka Ohta