Date: Sat, 30 Aug 1997 01:31:13 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: shocking@mailbox.uq.edu.au (Stephen Hocking) Cc: hackers@FreeBSD.ORG, andrew@zeta.org.au Subject: Re: shared libraries? Message-ID: <199708300631.BAA00303@dyson.iquest.net> In-Reply-To: <199708300523.PAA02145@mailbox.uq.edu.au> from Stephen Hocking at "Aug 30, 97 03:23:19 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Stephen Hocking said: > > [Snippage re performance impact of shared libs] > > My own take on this is that I've seen less memeory consumption when using > shared libs uon an SVR4 system (as measured by top, sar et al). With shared > libs and the cache issue, clustering commonly used routines together has a > positive performance impact (indeed, there whas a good paper put out by the > SVR3 guys when they implemented the shared libc as how they had to re-order to > reduce resident set size and so forth). > Actually, I have seen performance go through the floor when one of my customers decided to used shared libs on an SVR4 MIPS box (we are talking about multiple second symbol resolution.) It really depends on the app. It is usually silly to link X apps static (except in the case of licensing issues -- where someone might not have all of the shared libs), but it is equally silly to link a shell dynamic. The point that I have been trying to make is that it isn't a no-brainer to use shared libs. In fact, when doing lots of forks or execs, almost all systems see a performance hit. On an X86 it is even worse because of the PIC issues. (MIPS architectures don't exact quite the same performance penalties -- due to both inst. set. and the number of available registers.) For example, look at the shell. How can a shared lib improve the performance? If you have 100 shells running, why would you use a shared lib with a sparse .data and .bss? Remember, most U**X type OSes share .text and many share unmodified .data. A program ends up being it's own ideal shared library, with practically none of the disadvantages (like PIC, sparse image (which translates to cache, TLB, COW overhead), and general VM performance issues such as more internal datastructure sizes.) You will often have alot of pages COW'ed or created when only a few bytes in each are actually used. FreeBSD is often used on www server or sh server applications -- it often isn't a gain to use shared libs in that case. But say, if you have an app with lots of support code, and you only run a few copies of each program (e.g. X), then shared libs can be helpful. Regarding SVR3, it didn't do symbol resolution at program startup, so that situation was better. It still had a bit of a problem with .data being sparse. Maintaining the SVR3 shared libs was much more of a pain though. > > I have a collection of references > floating around for all this, including one paper by a guy called Jerry > Breecher(sp?) in which he re-ordered modules in shared objects on Unix systems > and a Data general system and saw reduced memory usage and pageout rates. It > appeared that a re-ordering based on the simple ranking given by prof et al > gave most of the benefits of schemes using fancy time-ordering techniques > (what modules were most used at each phase within a program). I've been > meaning to hack together a simple perl script to automate this process - > perhaps I ought to bump up the priority of this a bit. > That would be nice, because it could help our performance. DG and I have played with reordering libc. It is truely silly to have all of the system call stubs scattered throughout the entire lib (like we did at one time, and maybe even now.) > > It's not a new idea of course, look at the MIPS tools pixie and coord (which > admittedly are more biased towards restructuring basic blocks for otimal cache > I worked on/with the Tandem FT boxen, and the MIPS tools were kind-of impressive (IMO.) Eventually, they improved the shared lib support so that program startup dropped to the sub-second time (large program, on R4400.) It isn't bad to support shared libs on an OS, but they are not a panacea. -- John dyson@freebsd.org jdyson@nc.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708300631.BAA00303>