NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/unix/bsd/10292

Internet Message Format | 1992-12-16 | 3.6 KB

Xref: sparky comp.unix.bsd:10292 comp.unix.wizards:5255
Path: sparky!uunet!mcsun!uknet!gdt!aber!aberfa!pcg
From: [e-mail] (Piercarlo Grandi)
Newsgroups: comp.unix.bsd,comp.unix.wizards
Subject: Re: Shared lib benchmarks, and experiences
Message-ID: <[e-mail]>
Date: 11 Dec 92 19:14:32 GMT
References: <[e-mail]>
    <[e-mail]>
Sender: [e-mail] (USENET news service)
Reply-To: [e-mail] (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth
Lines: 58
In-Reply-To: [e-mail]'s message of 9 Dec 92 21: 34:42 GMT
Nntp-Posting-Host: aberdb

On 9 Dec 92 21:34:42 GMT, [e-mail] (H.J. Lu) said:

hlu> (othman (EEE/Div 4)) writes:

othman> I've installed Joerg's shared lib with little problem.
othman> The improvement in code size is significant for small programs
othman> but can be worse for larger programs such as cc1. cc1 using
othman> shared lib is actually larger than static lib, but SysV manual
othman> warns of this problem.

hlu> Very strange. I though shared libs always won. At least it is true
hlu> under Linux. No matter how large/small the program is, the code
hlu> size is always smaller if the program is linked with shared lib.

I think 'othman' was referring to the (dynamic) working set size, not
the (static) code size, as this was what the SysV manuals were referring
to.

Shared libraries often make an executing process' working set larger, if
they are not built such that procedures are likely to be invoked next to
each other in time are next to each other physically. With nonshared
libraries only the .o files actually required by the program get linked
with it, and usually each .o gets linked in immediately after the first
reference to a procedure in it, which also helps ensure that there is
some better clustering.

It would be nice to have a tool that does a clustering of procedures
based on their *dynamic* reference patterns, so as to minimize the
working set of a shared library; lacking this I always build a shared
library using "`lorder *.o | tsort`" rather than "*.o"; putting the
object files in linearized call order should _help_ ensure that
procedures that call each other statically are next to each other.

  Note that this only only clusters together .o files that refer *to
  each other* and *statically*. It would be best to cluster together .o
  files whose procedures are called next to each other by the average
  client of the library, but without profiling, we cannot know.

A reason for hope is that on unloaded machines there is plenty of free
memory and so working set size matters less; on loaded machines several
processes are going to share a given library (hopefully), exercising
different parts of it, so (hopefully) the working sets will overlap and
cover most of it, minimizing the problerm of reducing each. Also, if
several processes are sharing a library, the savings because of the
sharing will likely overwhelm the rise in working set for each process.

This means that the likes of libc, libXt and libX11 should be shared;
odds are that lots of *different* executable images will refer to them.

  The benefits for a shared library accrue if there are many different
  executable *images* using it, not *processes*; if there are many
  processes, but all arise from the same executable image, then whatever
  library is linked in that image is already shared with that image's
  text section.
--
Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <[e-mail]>
  E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  alle orecchie del suo divino protettore, il dio della barzelletta