Return to BSD News archive
Xref: sserve comp.unix.bsd:9049 comp.unix.wizards:28015 Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!uunet!mcsun!uknet!gdt!aber!aberfa!pcg From: pcg@aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.bsd,comp.unix.wizards Subject: Re: Shared lib benchmarks, and experiences Message-ID: <PCG.92Dec11191433@aberdb.aber.ac.uk> Date: 11 Dec 92 19:14:32 GMT References: <1992Dec3.071056.27426@ntuix.ntu.ac.sg> <1992Dec9.213442.18980@serval.net.wsu.edu> Sender: news@aber.ac.uk (USENET news service) Reply-To: pcg@aber.ac.uk (Piercarlo Grandi) Organization: Prifysgol Cymru, Aberystwyth Lines: 58 In-Reply-To: hlu@eecs.wsu.edu's message of 9 Dec 92 21: 34:42 GMT Nntp-Posting-Host: aberdb On 9 Dec 92 21:34:42 GMT, hlu@eecs.wsu.edu (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 <pcg@aber.ac.uk> E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero alle orecchie del suo divino protettore, il dio della barzelletta